Re: [GENERAL] ECPG SET CONNECTION
On 14.05.2015 19:35, Bruce Momjian wrote: On Fri, May 31, 2013 at 02:26:08PM +0200, Leif Jensen wrote: Hi guys. In the ECPG manual (including latest 9.1.9) about ECPG SQL SET CONNECTION connection name; it is stated that This is not thread-aware. When looking in the ecpg library code connect.c for ECPGsetconn( ... ), it looks very much like it is thread-aware if translated with the --enable-thread-safety option. What should I believe ? Can someone comment on this report from 2013? Sorry, it seems I missed this email. Yes, the code should be thread-aware, at least I don't know of any problems with it. It appears to me that the docs haven't been updated by the patch that made ecpg work with threads back in the day. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] --enable-thread-safety bug
On Sat, Mar 22, 2008 at 04:58:28PM -0400, Steve Clark wrote: Not exactly sure what you are asking about - descriptors and auto allocating. So I guess you don't use either feature. :-) The program processes about 80 packets a day, which can update several tables. It runs continously reading udp packets from systems at remote locations coming in over the internet. But the code for processing all thoss statements is the same, with and without threading enabled. One code that differs is allocation of sqlca, but given that this structure has a mere 215 bytes (about). Even if it was allocated 80 times it would make up for a memory loss of about 164MB. Which brings up the question how long the application runs until it segfaults. As Tom already pointed out, without more information there simply is no way for us to find out what's going on. We are more than willing to dig into it, but we need more to be able to. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! - Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] --enable-thread-safety bug
On Sat, Mar 22, 2008 at 12:51:30PM -0400, Steve Clark wrote: My program had no threads - as I pointed out if I change the default Makefile in the FreeBSD ports system to not enable thread safety my programs runs just fine for days on end. It appears to me without any kind of close examination that there is a memory leak in the ecpg library when enable thread safety is turned on. There are just a few variables covered by ENABLE_THREAD_SAFETY. I wonder how the program manages to spend so much time allocating memory to eat all of it. Could you give us some more info about your source code? Do you use descriptors? Auto allocating? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
Re: [GENERAL] ecpg problem
I just committed the attached small fix to CVS HEAD and the 8.3 branch.
This should fix your problem.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL!
diff --exclude CVS -ru /home/postgres/pgsql-ecpg/preproc/type.c preproc/type.c
--- /home/postgres/pgsql-ecpg/preproc/type.c 2007-12-21 15:33:20.0 +0100
+++ preproc/type.c 2008-03-02 11:49:11.0 +0100
@@ -259,7 +259,7 @@
ECPGdump_a_simple(o, name,
type-u.element-type,
- type-u.element-size, type-size, NULL, prefix, type-lineno);
+ type-u.element-size, type-size, NULL, prefix, type-u.element-lineno);
if (ind_type != NULL)
{
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [GENERAL] ecpg problem
On Fri, Feb 29, 2008 at 11:27:25AM -0500, Steve Clark wrote: Actually it appears to work in 8.2.5 but be broken in 8.2.6 and 8.3.0. Are you really sure? It appears to me that there was no change between 8.2.5 and 8.2.6 that could affect ecpg's handling of arrays of varchar. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Errors with run_build.pl - 8.3RC2
On Tue, Jan 22, 2008 at 11:52:08AM +, cinu wrote: Even though these errors are existing, at the end the latest version is getting downloaded and when I do a regression testing it goes through. Can anyone give me Regression tests have to test error handling too, so some errors might exactly be what you should see. ERROR: duplicate key value violates unique constraint test_pkey STATEMENT: insert into test ( i , j ) values ( 7 , 12 ) ERROR: more than one row returned by a subquery used as an expression STATEMENT: select i from test where j = ( select j from test) LOG: unexpected EOF on client connection ERROR: relation nonexistant does not exist STATEMENT: select * from nonexistant These errors are supposed to be there. Comments in the code even tell you why. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] ECPG problem with 8.3
On Mon, Jan 14, 2008 at 10:57:45AM -0500, Tom Lane wrote: I'm concerned about this too. We'll at least have to call this out as an incompatibility in 8.3, and it seems like a rather unnecessary step backwards. I thought I had send an email asking for comments back when this was implemented. But given that I cannot this email anymore I wonder if it really went out. My bay, sorry. Given that people seem to use this feature I'm more than willing to implement it, although it might become a bit hackish. Given that fetch is not a preparable statement we can live with the slightly inconsistent variable handling I think. Expect a patch soon. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] ECPG problem with 8.3
On Sun, Jan 13, 2008 at 03:01:04PM +, Peter Wilson wrote: that fixes that problem. My build now gets further, but I get an error and a seg-fault later in the build. Whow, you're really stress testing it. Thanks a lot! This is what we need. Apart from the seg-fault, is there any particular reason I can't use a The segfault is fixed in CVS. Reason was that on finding the variable it set an error message but not the normal return value and then tried to proceed anyway. variable in the FETCH anymore? It's always worked in the past and would seem to be an important capability. Yes. ECPG move to the latest backend protocol version to be able to prepare statements correctly. However, with this protocol my own addition to the standard, namely a variable as fetch count, is not supported anymore. But there is a simple workaround. Just sprintf the statement to a string and thereby replace the count variable with its content and then EXEC SQL EXECUTE the string variable should do the job. Hope this helps. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] ECPG problem with 8.3
On Fri, Jan 11, 2008 at 11:51:08PM +, Peter Wilson wrote: I've just tried compiling our project against the 8.3RC1 code. This is the first time I've tried any release of 8.3. ... crbembsql.pgC:254: error: invalid conversion from `int' to `ECPG_statement_type' crbembsql.pgC:254: error: initializing argument 6 of `bool ECPGdo(int, int, int, const char*, char, ECPG_statement_type, const char*, ...)' It seems that some compilers don't like int/enum aliasing here. I changed this in CVS could you please re-try? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Abbreviation list
On Thu, Oct 18, 2007 at 04:46:00PM -0700, Steve Crawford wrote: ECPG - Embedded SQL in C ?? Correct. And the PG part should be obvious. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Version 8.2.4 ecpg - function not found
On Thu, Sep 06, 2007 at 08:51:54AM -0400, Paul Tilles wrote:
ECPGis_informix_null
ECPGset_informix_null
In 8.2.4, I do not see these functions. Instead, I see functions
ECPGis_noind_null
ECPGset_noind_null
Are they functionally the same?
Yes. The 7.4 version had some naming problems.
Also, the 8.2.4 doc (Section 31.9.1) describes the functions risnull and
rsetnull. These are the names of the original Informix functions. Are
they available for use through ecpg?
Yes, they are. Just have a look at compatlib. They essantially only call
the above mentioned functions:
int
rsetnull(int t, char *ptr)
{
ECPGset_noind_null(t, ptr);
return 0;
}
int
risnull(int t, char *ptr)
{
return (ECPGis_noind_null(t, ptr));
}
Hope this helps.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] ecpg: dtime_t vs timestamp
On Tue, Aug 28, 2007 at 10:59:42AM -0400, Paul Tilles wrote:
We have upgraded from Version 7.4.x to Version 8.2.4.
In 7.4.x, we use the Informix compatibility functionality to use legacy
code.
Our .pgc code looks as follows:
...
This is indeed a bug. Thanks for reporting it.
What happens is that ecpg defines the data types, but does not use that
define while in C code. I just committed patches to CVS. I also attach
it here. Could you please try if this fixes your problem?
Thanks.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
--- preproc/ecpg.c 8 Feb 2006 09:10:04 - 1.94
+++ preproc/ecpg.c 29 Aug 2007 13:50:55 -
@@ -185,11 +185,6 @@
char informix_path[MAXPGPATH];
compat = (strcmp(optarg, INFORMIX) == 0) ? ECPG_COMPAT_INFORMIX : ECPG_COMPAT_INFORMIX_SE;
- /* system_includes = true; */
- add_preprocessor_define(dec_t=decimal);
- add_preprocessor_define(intrvl_t=interval);
- add_preprocessor_define(dtime_t=timestamp);
-
get_pkginclude_path(my_exec_path, pkginclude_path);
snprintf(informix_path, MAXPGPATH, %s/informix/esql, pkginclude_path);
add_include_path(informix_path);
--- preproc/pgc.l 22 Sep 2006 21:39:58 - 1.150
+++ preproc/pgc.l 29 Aug 2007 13:50:55 -
@@ -48,6 +48,8 @@
static void parse_include (void);
static void check_escape_warning(void);
static bool ecpg_isspace(char ch);
+static bool isdefine(void);
+static bool isinformixdefine(void);
char *token_start;
int state_before;
@@ -671,29 +673,8 @@
}
SQL{identifier} {
ScanKeyword*keyword;
- struct _defines *ptr;
-
- /* How about a DEFINE? */
- for (ptr = defines; ptr; ptr = ptr-next)
- {
- if (strcmp(yytext, ptr-old) == 0 ptr-used == NULL)
- {
-struct _yy_buffer *yb;
-
-yb = mm_alloc(sizeof(struct _yy_buffer));
-
-yb-buffer = YY_CURRENT_BUFFER;
-yb-lineno = yylineno;
-yb-filename = mm_strdup(input_filename);
-yb-next = yy_buffer;
-
-ptr-used = yy_buffer = yb;
-yy_scan_string(ptr-new);
-break;
- }
- }
- if (ptr == NULL)
+ if (!isdefine())
{
/* Is it an SQL keyword? */
keyword = ScanKeywordLookup(yytext);
@@ -765,38 +746,10 @@
}
C{identifier} {
ScanKeyword *keyword;
- struct _defines *ptr;
-
- if (INFORMIX_MODE)
- {
- /* Informix uses SQL defines only in SQL space */
- ptr = NULL;
- }
- else
- {
- /* is it a define? */
- for (ptr = defines; ptr; ptr = ptr-next)
- {
-if (strcmp(yytext, ptr-old) == 0 ptr-used == NULL)
-{
- struct _yy_buffer *yb;
-
- yb = mm_alloc(sizeof(struct _yy_buffer));
- yb-buffer = YY_CURRENT_BUFFER;
- yb-lineno = yylineno;
- yb-filename = mm_strdup(input_filename);
- yb-next = yy_buffer;
-
- ptr-used = yy_buffer = yb;
-
- yy_scan_string(ptr-new);
- break;
-}
- }
- }
-
- if (ptr == NULL)
+ /* Informix uses SQL defines only in SQL space */
+ /* however, some defines have to be taken care of for compatibility */
+ if ((!INFORMIX_MODE || !isinformixdefine()) !isdefine())
{
keyword = ScanCKeywordLookup(yytext);
if (keyword != NULL)
@@ -1347,3 +1300,61 @@
return true;
return false;
}
+
+static bool isdefine(void)
+{
+ struct _defines *ptr;
+
+ /* is it a define? */
+ for (ptr = defines; ptr; ptr = ptr-next)
+ {
+ if (strcmp(yytext, ptr-old) == 0 ptr-used == NULL)
+ {
+ struct _yy_buffer *yb;
+
+ yb = mm_alloc(sizeof(struct _yy_buffer));
+
+ yb-buffer = YY_CURRENT_BUFFER;
+ yb-lineno = yylineno;
+ yb-filename = mm_strdup(input_filename);
+ yb-next = yy_buffer;
+
+ ptr-used = yy_buffer = yb;
+
+ yy_scan_string(ptr-new);
+ return true;
+ }
+ }
+
+ return false;
+}
+
+static bool isinformixdefine(void)
+{
+ const char *new = NULL;
+
+ if (strcmp(yytext, dec_t) == 0)
+ new = decimal;
+ else if (strcmp(yytext, intrvl_t) == 0)
+ new = interval;
+ else if (strcmp(yytext, dtime_t) == 0)
+new = timestamp;
+
+ if (new)
+ {
+ struct _yy_buffer *yb;
+
+ yb = mm_alloc(sizeof(struct _yy_buffer));
+
+ yb-buffer = YY_CURRENT_BUFFER;
+ yb-lineno = yylineno;
+ yb-filename = mm_strdup(input_filename);
+ yb-next = yy_buffer;
+ yy_buffer = yb;
+
+ yy_scan_string(new);
+ return true;
+ }
+
+ return false;
+}
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] ECPG: inserting NULL values when using prepared statements
On Mon, Apr 02, 2007 at 11:53:50AM -0500, Anders Nilsson wrote: The situation: A loop that inserts thousands of values into a table. In hopes of optimizing the bunches of inserts, I prepared Sorry, but that won't work. ECPG only simulates statement preparation. a statement like the follows: insert into some_table_name ( value, id, date ) values ( ?, ?, ? ) then executing the prepared statement identifier numerous times using already declared host variables. The problem: Some of these values are null. Is there a way to specify a null value without having to rewrite the statement with the explicit NULL replacing the ? ? Yes, use an indicator when instanciating the statement. (If this works) if I were to use indicator variables when inserting, what would the syntax be? So far, indicator variables work great when fetching, though I just can't seem to get it right when inserting / updating. Or, if there is another method to specify NULL values, that would be great as well. Just an example from the regression suite: /* use indicator in insert */ exec sql insert into test (id, str, val) values ( 2, 'Hi there', :intvar :nullind); So this is essantially the same as with fetch. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Stats collector frozen?
On Sat, Jan 27, 2007 at 03:17:14PM +0100, Magnus Hagander wrote: Seems HEAD now passes thie check stage on at least snake and bandicoot. They're now exposing another problem with ECPG though... This should be fixed now. I just missed to change MinGW expected files when I changed the tests. That's why I prefer to have no platform specific expected files. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org/
Re: [GENERAL] Shared Objects (Dynamic loading)
On Wed, Aug 23, 2006 at 11:41:50PM -0600, Michael Fuhr wrote: Is there a reason this server-side code is using ECPG instead of SPI? To make sure it doesn't work? There is NO guarantee that ECPG will work in this scenario. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Connection string
On Fri, Aug 18, 2006 at 02:54:19PM -0600, Michael Fuhr wrote: It works with a double-quoted string but not with a single-quoted string as the documentation mentions. It's not supposed to work with single-quoted strings. This is a documentation bug. Or does anyone think we should support single quotes too? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Connection string
On Tue, Aug 15, 2006 at 07:31:31PM -0600, Michael Fuhr wrote: Will that be a minor fix that can be backpatched or will it be invasive enough to be fixed only in HEAD? I'll submit a documentation I just fixed it and applied the patch to 8.0 and 8.1 too. Please test it. 7.4 is way more different so I'd prefer to not touch it anymore. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [NOVICE] [GENERAL] DB insert Error
On Wed, Aug 16, 2006 at 11:40:40AM -0400, Jasbinder Bali wrote: [2998]: ECPGexecute line 97 Ok: INSERT 0 1 This is a backend message saying that the insert command was executed error free and inserted one record. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Connection string
On Sun, Aug 13, 2006 at 01:50:13AM -0400, Harpreet Dhaliwal wrote: I'm really not able to connect to my database server. ... Again, your example works nicely for me. This has to be a problem with your local setup. You should get the same connection problem using psql on the same machine with the same connection setting. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Connection string
On Fri, Aug 11, 2006 at 04:40:36PM -0600, Michael Fuhr wrote: EXEC SQL CONNECT TO 'unix:postgresql://sql.mydomain.com/mydb' AS myconnection USER john; Should that be changed? It's wrong on two counts as far as I think so yes. Will you take care of it or should I submit a patch? I've noticed I you have the time to write the patch I woul dappreciate it. a few other discrepancies between the documentation and actual behavior, like examples with VARCHAR val; that the preprocessor rejects with ERROR: pointer to varchar are not implemented. Do you have an example? This surely looks like a bug. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Connection string
On Tue, Aug 15, 2006 at 05:59:23AM -0600, Michael Fuhr wrote: I'll submit a patch. However, in the case of string literals not working, is that a documentation bug or a code bug? Are they supposed to work? You shoudl be able to use a string constant or a char * variable as database name. There are a lot of test cases for connect available under ecpg/test/connect now. If string literals do not work we have fix it and add it to the test suite. a few other discrepancies between the documentation and actual behavior, like examples with VARCHAR val; that the preprocessor rejects with ERROR: pointer to varchar are not implemented. Do you have an example? This surely looks like a bug. See several code examples in the last half of the Using Host Variables documentation: Ah, I see. It lacks the size information. Yes, this is a documentation bug. varchar is translated to a struct with an char array whose size needs to be given. I think it never worked without it. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] Connection string
On Thu, Aug 10, 2006 at 11:57:14AM -0400, Harpreet Dhaliwal wrote: This is a simple code snippet that i've written to check if i can connect to the postgres database server residing at IP 192.168.0.123. DB name is xyz Also, user account jsb has the access to the database xyz. #include stdio.h EXEC SQL INCLUDE sqlca I take it you did not copy the file verbatim because this seem to lack the ';'. EXEC SQL CONNECT TO 'tcp:postgresql://192.168.0.123/xyz' USER jsb The correct syntax would be: EXEC SQL CONNECT TO tcp:postgresql://192.168.0.123/xyz USER jsb; This should work at least it does for me. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] Connection string
On Fri, Aug 11, 2006 at 07:01:55AM -0600, Michael Fuhr wrote: The ECPG Connecting to the Database Server documentation does have an example for Unix sockets with quotes: EXEC SQL CONNECT TO 'unix:postgresql://sql.mydomain.com/mydb' AS myconnection USER john; Should that be changed? It's wrong on two counts as far as I think so yes. I'm thinking that example should be: EXEC SQL CONNECT TO unix:postgresql://localhost/mydb AS myconnection USER john; Right. In practice, it is probably less error-prone to use a (single-quoted) string literal or a variable reference. which might be the source of confusion here. This should be fixed. You're absolutely right. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [GENERAL] DB connectivity from a client machine
On Tue, Aug 08, 2006 at 05:25:12PM -0400, Jasbinder Bali wrote: Why I'm asking this is (though generally m/c hosting the middle tier component can connect to the m/c hosting the Db without any DB client installed) because i tried to run ecpg in the middle tier m/c and it doesn't work. Well it would definitely not work coz ecpg comes with postgres. This is about the third time you claim ecpg doesn't work. Would you please be so kind to explain what doesn't work? Of course ecpg can be run on a machine without a PostgreSQL server. And programs compiled with ecpg also do not need a server on the same machine, why should they? This is why Debian for instance has a seperate ecpg package. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] ECPG and COPY
On Mon, Mar 06, 2006 at 10:15:06AM -0500, Bruce Momjian wrote: Added for ecpg TODO: o Add COPY TO STDIN / STDOUT handling COPY TO STDOUT has been implemented, but I'm unsure whether COPY FROM STDIN really makes sense. Does anyone know a real life example where this would be needed and the work couldn't be done easier using psql? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] ECPG and COPY
On Wed, Aug 02, 2006 at 12:03:45PM +0200, Florian Weimer wrote: * Michael Meskes: COPY TO STDOUT has been implemented, but I'm unsure whether COPY FROM STDIN really makes sense. Does anyone know a real life example where this would be needed and the work couldn't be done easier using psql? COPY FROM STDIN saves lots of network round-trips. So what? Could you please explain what this has to do with my original question? Somehow I don't get it, sorry. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] ECPG and COPY
On Wed, Aug 02, 2006 at 09:49:40AM -0400, Bruce Momjian wrote: I assumed that ECPG did something special with TO STDOUT, like other interfaces do. This is not the case (that is, STDOUT is really standard output, so the functionality is not very useful. I am confused. STDOUT is already implemented. It was STDIN that we were asking if it was valuable. Yes, I was asking about FROM STDIN. TO STDOUT has been added lately. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] ECPG. Badly stuck
On Tue, Jul 25, 2006 at 02:46:02PM -0400, Jasbinder Bali wrote: Forget about cursors. Singleton queries are also not working. Great statement. Tried writing the follwoing code but doesn't give me any result. Don't know if i have to do somethin else apart from what i've already done. How about giving us at least the table definition and the system information? Yes, I know I asked for those in my last email too. And please tell us what makes you sure it doesn't work? Just no output? Or empty output? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] ECPG usage
while(1)
{
EXEC SQL FETCH IN c_movie INTO :movie_title;
printf(%s\n,movie_title);
movie_title = NULL;
}
free (movie_title);
As a side note, you should free movie_title each time, not just set it
to NULL if you use auto allocation.
At while loop, it keeps on looping forever and my table has 2 records for
the query that is eventually build.
Does that mean EXEC SQL WHENEVER NOT FOUND DO BREAK; is not
working.
No, that would be the first time I hear about this. You could run your
program with debugging enabled (see test/*.pgc for example). Also I'd
like to know which version of ecpg you're using.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] ECPG and Curors.
On Mon, Jun 12, 2006 at 11:14:24PM -0400, Peter L. Berghold wrote: what I don't see is how to detect that I've fetched the last row from a query. Is there more complete doco on this process somewhere? Just look for exec sql whenever not found ... Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [GENERAL] Best high availability solution ?
But you have a point that having a contact for postgresql support is a very good idea anyway ! Here ya go: http://www.commandprompt.com/support (DISCLAIMER: I represent the company) Josh, don't you think the better starting point when looking for support would be http://www.postgresql.org/support/professional_support ? :-) There are support companies in France and other parts of Europe which might be a better idea for a company in France. After all I think a situation like this might need some on-site availability. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: Fw: [GENERAL] ecpg error -- DbPg_cre_sect_buf.pgc:1334: ERROR: syntax error at or near RELEASE
[Catching up on my old email, well at least sort of. Sorry for the delay.] On Wed, Feb 22, 2006 at 10:22:39AM -0500, [EMAIL PROTECTED] wrote: Will this still result in the closed DB connection that the ROLLBACK RELEASE used to give me? ECPG just sends the queries to the backend the way you write them. It does some parsing so you can be noticed if there are syntax errors. It also does some translations to get the C variables into the SQL code and vica versa, but all other statement with the exception of prepare/execute are transferred as-is. Or at least that should be the case. :-) So to see if ROLLBACK has the behaviour you need you have to check the backend documentation. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] ECPG and COPY
Yes, it's still an open report. Sorry, about that and all the other open bug reports/feature requests. I do not have the time at the moment to even reproduce bugs. Hopefully this will become better in the near future. Should we add this to TODO? Anything else? Yes, please add it. I do have some more open bug reports/feature requests, but I'd like to reproduce things first before we add to the docs. Sometimes it's easier to fix it than to add it. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] ECPG and COPY
Am Freitag, 24. Februar 2006 05:26 schrieb Wes: I found this in the archives: http://archives.postgresql.org/pgsql-interfaces/2004-04/msg5.php With 8.x, is it still true that with ECPG, it is not possible to use COPY inline - I'd have to write the data to a file, then 'COPY FROM filename' (or use direct libpq API calls instead of ECPG)? Yes, it's still an open report. Sorry, about that and all the other open bug reports/feature requests. I do not have the time at the moment to even reproduce bugs. Hopefully this will become better in the near future. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] eqpg doesn't like bit fields
Am Mittwoch, 1. Februar 2006 15:46 schrieb Noble, Robert: I get the following error from ecpg when it encounters a structure containing a bit field: ... A quick guess would be that the parser simply doesn't know this syntax. I'll have a look at it. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [GENERAL] ECPG examples...
On Thu, Sep 01, 2005 at 02:10:04PM -0600, Cristian Prieto wrote: Hello, I've been reading a little the ECPG (Embedded SQL in C) and the doc is (I guess) very clear, but I cannot find any examples in the documentation, any idea where to get examples? inside the pgsql source code? Yes, there us an example directory in the source code: .../src/interfaces/ecpg/test Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] ecpg and C++
On Thu, Jul 28, 2005 at 05:07:04PM -0400, Peter L. Berghold wrote: If I wanted to embed SQL code in a C++ file is there a way to use ecpg to generate the proper C++ files? Sorry for the late answer, but I have been on vacation and some business trips, so I'm just catching up on my mail backlog. What exactly do you want to get and do not? ecpg is supposed to be a C precompiler, but it should at least accept most C++ stuff as well. That of course means that it is output as read, so remains C++. The internal code produced remains C of course unless you implement a different output engine. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [GENERAL] Postgresql replication
Am Mittwoch, 24. August 2005 14:21 schrieb Carlos Henrique Reimer: One possible solution is replicate the headquarter DB into the two branches. I read about slony-i, but then the replicated DBs will be read-only. That's because it's a master-slave replication. If you could sync the slave back to the master it would be a master itself. I think I´m looking for a master-slave assynchronous solution. I know pgReplicator can do it, but I think the project is not active any more. But Slony does master/slave replication. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [GENERAL] ECPG - Timestamp to ascii Conversion PG version 7.4
On Thu, May 05, 2005 at 11:07:10AM -0700, Don Laurine wrote: We are currently transitioning to Postgresql 7.4 from Informix. IN ECPG, is there a Postgresql function which will convert the timestamp data type to a string equivalent. INFORMIX has the dtcvasc function but I prefer not to use the -C compatibility option. I rather have a complete port and get away from INFORMIX. There is. You can use PGTYPEStimestamp_from_asc instead. You just have to link against pgtypeslib. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] ECPG Segfaulting on EXEC SQL connect
On Wed, Jan 19, 2005 at 06:07:24PM +0100, Hans-Michael Stahl wrote: It is from a very large production example. I have to work a bit to trim this down to a small example. I'llt try to provide an example. I now also remember that the problem *only* occurs with dynamically prepared statements with cursors, static statements with cursors work w/o problems. Okay, please let me know when you have a test case. I'd surely like to fix that. :-) Go SF 49ers! What's that? My favourite NFL team, that's professional american style football in the US. Go Rhein Fire! And that? My favourite and local NFLE team, that's professional (more or less) american style football in Europe. Use PostgreSQL! Yes, when Embedded SQL works again :-) Okay, let's work on that one. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] ECPG Segfaulting on EXEC SQL connect
On Tue, Jan 18, 2005 at 05:49:05PM +0100, Hans-Michael Stahl wrote: This also happens with Postgresql 7.4. under SUSE Linux 9.1 (kernel 2.6.4-52) The last version for which embedded SQL worked well for me was 7.3. The same source which worked fine under 7.3 for many months stopped working with my switch to 7.4.2. :-( Interesting. And it not only happens during connect, but also during a select. It is very difficult to debug, since often the stack is destroyed and a backtrace in gdb does not work. From what I can see it is always related to calls of malloc/free/realloc issued by libpq. I would be happy to help debugging this. But up to now I didn't even know about this problem. Could you please send me a test case so I can reproduce this? Also did you try using 8.0? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] ECPG Segfaulting on EXEC SQL connect
On Tue, Dec 28, 2004 at 10:16:04PM -, John Smith wrote: I'm trying to convert a series of C programs written originally using Informix ESQL to use Postgres' ECPG. ... 575 EXEC SQL connect to pdev_changename; ... I'm using Postgres 8.0.0rc1 on Redhat 9 (kernel 2.4.20-31.9). The same thing happens on fedora core 3, and using Postgres 7.4.6-1.FC3-1. Could you please try rc3? I did fix some segfaults in the connect statement. However, I'm not sure you hit the same bug, actually I expect it to be a different one. The ability to define variables of type timestamp etc. is so useful, so I really want to keep using -C INFORMIX if I can. You can use the datatypes without informix mode. You just have to include the pgtypes_*.h header files yourself. Can anyone help shed any light on this? I will try if you could send me an example to reproduce the problem. As you said it does not happen on a small self written test case. Maybe you can send me one of your source files stripped down to just connect. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] ECPG Mac OS X
On Wed, Sep 15, 2004 at 01:28:14AM -0400, Richard Connamacher wrote: Also, anyone know if it can parse Objective C files? They're basically identical to c language files, with two added constructs: method calls, which are surrounded by brackets: ... It depends where these constructs are used. If they are used inside an SQL declare section it will probably cause trouble as ecpg does not know them. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [GENERAL] Problem with ecpg
On Tue, Dec 30, 2003 at 11:39:29AM -0300, Carmen Gloria Sepulveda Dedes wrote: When I execute an ecpg program (in an insert on a table), I get this What do you mean with this? The ecpg program does an insert? Or how do you use a program in an insert? Also it would surely help if you could provide a snippet of the code or even better a small test case. michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] Photos of PostgreSQL booth
On Thu, Dec 25, 2003 at 06:25:34PM -0400, Marc G. Fournier wrote: whose manning the booth? The one one the photos is Noel Koethe. He manned the booth together with Peter Eisentraut and me. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Photos of PostgreSQL booth
On Fri, Dec 26, 2003 at 02:04:09PM -0400, Marc G. Fournier wrote: One thought for future booths would be to have a group photo done that we can add to the web site ... ? :) Yes, good idea. :-) Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] ecpg question
On Tue, Dec 23, 2003 at 02:06:14AM -0500, George Gensure wrote: EXEC SQL SELECT * FROM foo() AS TBL( c int, i int ); or any other query with multiple columns to a TBL description causes a segfault in ecpg. It also concerns me that all other symbols are I just fixed this. The reason was a usage of ',' instead of make_str(,) in the cat_str call. Since the argument is free'd afterwards it couldn't work. Ecpg does not lowercase all symbols per default but only those that need some special treatment like keywords. There's no logic to just lowercase everything as this is not requiered IIRC. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Embedded Vacuum Still Not Working...
On Wed, Nov 19, 2003 at 11:16:18PM -0700, [EMAIL PROTECTED] wrote: Turning OFF AUTOCOMMIT as suggested didn't solve the problem. Sure as it is OFF by default. You have to turn it ON. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [GENERAL] Problem with exec sql include
On Wed, Nov 19, 2003 at 11:09:58AM -0300, Carmen Gloria Sepulveda Dedes wrote: I know that I can include the typedef at DECLARE SECTION, but I don't want to use that (test.h and test.pgc are only examples of the problem ECPG does not parse anything outside EXEC SQL blocks, so how else should it lear about your struct definition? You can of course use a EXEC SQL TYPE command to define it for ECPG as well. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] Problem with exec sql include
On Wed, Nov 19, 2003 at 12:26:07PM -0300, Carmen Gloria Sepulveda Dedes wrote: In the test.pgc file, I do: EXEC SQL BEGIN DECLARE SECTION; exec sql include test; struct_cursor t_cursor; EXEC SQL END DECLARE SECTION; ... and it works fine. It is correct Depends on what test.h contains. ecpg has to learn the definition of your struct somewhere. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [GENERAL] vacuum from ecpg
On Sat, Nov 15, 2003 at 11:31:08PM -0500, Bruce Momjian wrote: I might be wrong on this but I think that ecpg using transactions by default for each query. Perhaps turning on autocommit? Yep, use: EXEC SQL SET AUTOCOMMIT = ON; Or use 'ecpg -t'. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] Problem with ecpg
On Fri, Oct 31, 2003 at 11:20:27AM -0300, Carmen Gloria Sepulveda Dedes wrote: I have pgsql 7.3.4 and ecpg 2.10.0 Does exists a patch for this version? No, but it is rather simple. Just search for Unterminated in preproc/pgc.l and you'll find some mmerror() calls. In these calls just replace the ET_ERROR with ET_FATAL. That's it. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] EMBEDDED BUG?!?!?!?
On Mon, Oct 27, 2003 at 06:25:46PM -0700, [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] pgsql]$ postmaster -V postmaster (PostgreSQL) 7.1.3 This is pretty old already. EXEC SQL FETCH stck_info_crsr INTO :i_symbol :i_data_date, :i_open, :i_high, :i_low, :i_close, :i_volume; If this is taken literally from your program be aware that it cannot work as there is no , between :i_symbol and :i_data_date thus the latter is considered an indicator. when executing the fetch I get: sqlcaid = SQLCA sqlabc = 4.642502 sqlcode = 4.642506 sqlca.sqlerrm.sqlerrml = 49 sqlca.sqlerrm.sqlerrmc = Not correctly formatted int type: 29.25 line 500. Okay, it seems you did use the line above and try to read a real value into an int. BEFORE ** A 6 20020102.00 28.51 29.34 28.45 0 SYMBOL ** 'A ' D_DATE ** '0' i_open ** '20020102.00' VOLUME ** '0' The BEFORE, SYMBOL, D_DATE, i_open, VOLUME are from simple printf's. This is utterly useless unless you provide the sources so we can see what you actually printf. Apparently postgres is misreading the declaration of i_symbol and loading part of the declaration into the actual value of the data Nope. The 6 comes beyond the limit of the variable. The string simply seems to lack the delimitting \0. The folks who do embedded stuff need to take a look at this!! They just did. They even used their spare time to create a test case themselves as you did only provide code snippets. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [GENERAL] Postgres 7.4 : ECPG not Thread-safe
On Thu, Oct 09, 2003 at 04:42:18PM +0200, Thierry Missimilly wrote: I don't know if it is really link to Postgres and ECPG but if you modifiy pgbch.pgc in the way that the transaction is limited to BEGIN; END; , it will never hang. Do you mean it only hangs if you do automatic transaction starting? I mean if you use PGSQL implicit transactions and explicit BEGIN...END blocks it works well, but if you let libecpg start the transaction and just do a COMMIT every once in a while it is not? Well, i'm not an expert in Linux multi-thread, but it seems the thread Neither am I, so I have no idea where to look. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] numeric rounding
On Mon, Sep 29, 2003 at 12:47:05AM -0700, Gezeala 'Eyah' BacuXo II wrote: You can see I already added a value of 0.0001 to the computation but I also get the same results.. :( Why 0.0001? If you want to round to the second digit by cutting the number you have to add 0.005. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [GENERAL] ECPG bug or development choice
On Tue, Sep 09, 2003 at 02:48:19PM +0200, Thierry Missimilly wrote: I'm not sure it's a bug or it's normal, so i don't send it to pgsq-bugs. ... So, i use #ifdef ORACLE #else #endif preprocessing instructions to differentiate PG from Oracle Pro*c syntaxes. As a matter of fact we use EXEC SQL IFDEF, ... and do not parse any C/CPP code. running cpp before parsing leads to undesirable side effects. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] About GPL and proprietary software
On Sun, Aug 31, 2003 at 04:14:30PM -0400, Christopher Browne wrote: Sure? My understanding is that it does break GPL. That's why there's an LGPL. But since MySQL is double licensed and GPl is just one of the two it gets even more complicated. No, actually, it's pretty simple. ... The issue is that the CLIENT software is unavailable in other than GPL and other private license-for-money forms. In order for you to use MySQL, you have to link GPLed libraries in with your code. There are no LGPLed libraries; that would break MySQL AB's business model. Well, isn't that what I said? Okay, granted, you put it into words much better, but it looks like I wanted to say the same. MySQL has to GPL the libs to make sure they can make money with there other license. What I meant to say with LGPL is that this license is for such a usage, not that MySQl has LGPLed stuff. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] About GPL and proprietary software
On Sun, Aug 31, 2003 at 02:26:14PM -0500, Ron Johnson wrote: IANAL, but according to my understanding (1) proprietary s/w that dynamically links to GPL shared libraries has not broken the GPL. Sure? My understanding is that it does break GPL. That's why there's an LGPL. But since MySQL is double licensed and GPl is just one of the two it gets even more complicated. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM/Yahoo: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [GENERAL] Difficulties to do a migration from Oracle8i to PostgreSQL 7.3.3
On Sun, Jun 29, 2003 at 11:40:41AM +0200, Bruno BAGUETTE wrote: stucked on inserting PL/SQL packages... (Because there isn't the possibility to do PL/PgSQL packages currently). Sorry, I don't really understand this. PL/pgSQL is the PostgreSQL version of PL/SQL. He explains me that they have several frontend that uses that DB via the PL/SQL packages (dos, Gtk, Windows VisualC++, WAP (mobile phones), and Jini Java applications and he don't have the time and the knowledge to modify all theses applications in a very short time. (He is only DBA, not developper). You mean all these apps do is execute a PL/SQL procedure in Oracle? And they cannot change the syntax in the apps? But they can implement the logic in PostgreSQL as they do now in Oracle? Thus, he would like to make the PostgreSQL server to appears like an Oracle Server but I don't see anything about this in PostgreSQL documentation. As far as I know, PostgreSQL don't use the same architecture that Oracle (there isn't any Listener). Now this is something different IMO. PostgreSQL postmaster does the listening, but why do the apps need the very same appearance? So the trial to move from Oracle8i to PostgreSQL 7.3.3 will be probably delayed until the possibility to do that (PL/PGSQL packages), he will try to ask the developpers to add ODBC in their apps. How do they connect now? Native Oracle OCI? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-advocacy] [GENERAL] MySQL gets $19.5 MM
On Fri, Jun 20, 2003 at 11:14:02PM -0400, Tom Lane wrote: There are some, but I still disagree. The biggest advantage of PostgreSQL in my opinion has always been that it's a community project and not driven by some commercial interests. These are not mutually exclusive. Each developer has his own axe to grind, without doubt; I don't think it matters much whether his goals Okay, that's true. Actually what I wanted to say is the project must not rely on a kind of sponsorship. Maybe an example could make it more clear. Let's say a company approaches RH and says We need full replication and we're willing to pay for it, as this is still cheaper than buying the hwole stuff from Oracle or others.. Then RH pays you to do the work. I really like that. And it makes sense for all companies involved. What I do not like, and probably misunderstood in the original email, would be if RH says, Hey, we've contracted a good software developer to implement replication, no matter that he's not really interested in databases. And with no one paying RH for this work, they may decide at some point to just stop it. Or the developer leaves, etc. This of course is different than paying someone who's already a developer in this project. I love the way PGSQL is run, but have seen some unbelievable stuff in other projects. And it despises me to see companies, that do not even understand how free software development works, jump into a project and try to change it all, just to disappear after a few weeks. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [GENERAL] MySQL gets $19.5 MM
On Sat, Jun 21, 2003 at 11:40:52AM -0300, The Hermit Hacker wrote: I have no doubt that some of those features were 'pushed to the top of the TODO list' due to their business case, but I can't think of any that were against teh desires of the community ... were there? No, there were definitely not. I have no problem having TODOs list priorities changed and features developed due to business cases. What I meant to say was that companies should not just send some of their developers and act as if they want to take over. Sorry, I was just in a bad mood after seeing this stuff in another project. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [GENERAL] 7.1 upgrade problems
On Fri, Jun 08, 2001 at 04:37:42PM +0200, Andreas Tille wrote: The Debian package of postgresql 7.1 replaces the former extra package postgresql-pl and so I guess that plpgsql support is now included in the postgresql package. Unfortunately I get It is. ERROR: Unrecognized language specified in a CREATE FUNCTION: 'plpgsql'. Recognized languages are sql, C, internal, and created procedural languages. Could it be that you did not enable plpgsql? The Debian postinst script should do this for you: su postgres -c /usr/lib/postgresql/bin/enable_lang plpgsql --all Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [GENERAL] embedded sql pointer to structure question
On Fri, Mar 16, 2001 at 09:51:20PM +0100, Feite Brekeveld wrote: If I do that ( tried that already ) I get an eror message: pmr is not a pointer at the point where I reference to it in the query: ... Please read my mail completely: This should work. But be sure to use the latest CVS version as there was a small bug in this bug. I'm actually committing the fix right now. Should read "bug in this part" of course. :-) Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] embedded sql pointer to structure question
On Fri, Mar 16, 2001 at 12:58:06PM +0100, Feite Brekeveld wrote:
...
Exec sql begin declare section;
MYREC *pmr = mr;
exec sql end declare section;
...
I get the message :ERROR: The variable id is not declared
...
Yes, this is a known limintation. It's even listed in the TODO file. For
ECPG to be able to understand your variable it has to know the definition of
the struct. Since it is not listed in your declare section it cannot learn
the details and thus won't be able to parse the construct.
Please try:
exec sql begin declare section;
struct {
int id;
char value[40];
} *pmr;
exec sql end declare section;
This should work. But be sure to use the latest CVS version as there was a
small bug in this bug. I'm actually committing the fix right now.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [GENERAL] ECPG could not connect to the database.
On Mon, Jan 08, 2001 at 06:20:42PM +0100, Peter Eisentraut wrote: is not in libpq's current sources anymore. I fully agree with Peter E's reasons for removing it, too. We do not need to overload the definition of libpq's dbname parameter. Why? Sorry, it seems I missed his mail. Ouch, it *is* documented in ecpg(1). I guess if ecpg wants to provide this syntax (which it probably should, since the "sql connect to" syntax doesn't have any other provisions for host name, port, etc.) then it could take the code from libpq (it's still in there I think) and do the parsing before calling PQsetdbLogin(). This is a possibility of course. But why should this syntax be taken away from other apps using libpq? Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: [GENERAL] Using UnixODBC and postgresql
On Sat, Oct 07, 2000 at 12:51:54AM +1100, Danny wrote: 1)Does Postgresql with with UNIXODBC ? Yes, it does without a problem. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: [GENERAL] ecpg and include files
On Fri, Jun 30, 2000 at 02:08:17PM +0200, Jochen Weyermanns wrote: Path information and so on seem to be OK, moreover the ecpg used with option --v shows: ecpg - the postgresql preprocessor, version: 2.6.0 exec sql include ... search starts here: . /usr/local/include /usr/local/pgsql/include /usr/include End of search list. ( with sqlca.h at the right place: ls -l /usr/local/pgsql/include/sqlca.h leads to: -r--r--r-- 1 postgres daemon957 Jun 28 16:08 /usr/local/pgsql/include/sqlca.h ) The error message turns up even when I use ecpg -I/usr/loca/pgsql/include I'm at a loss here. I never expereienced something like this. What happens if you install sqlca.h into '.'? Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: [GENERAL] [Fwd: SQL3 recursive unions]
On Thu, Jun 15, 2000 at 03:58:40PM -0400, Ron Peterson wrote: PostgreSQL's TODO list (http://www.postgresql.org/docs/todo.html) makes reference to implementing SQL3 recursive queries. Where does this task fall in the overall priority of things? I hate to just whine without I want to implement this for some years now. But I haven't found the time to even start yet. offering to help, but I think this would be a rather big bite to chew. (Actually, I would be happy to help, if anyone had any suggestions about what I might be able to do) So at least we are two who are interested in this. Here's an example from DB2's documentation, cleaned up a bit: Is this SQL3 syntax? with rpl (part, subpart, quantity) as ( select root.part, root.subpart, root.quantity from partlist root where root.part = '01' union all select child.part, child.subpart, child.quantity from rpl parent, partlist child where parent.subpart = child.part ) Hmm, this doesn't look correct. What if a subpart is used by different parts? I think the second query needs an aggregate. But the above query certainly does solve the ancestor problem. Does anyone have an idea how DB2 executes such a statement? Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: [GENERAL] Using embedded SQL.
On Sat, Jun 03, 2000 at 05:37:32PM -0500, Robert J. Sprawls wrote:
I'm trying to learn embedded SQL in C. However, it's not working
and reading the documentation is not answering my question(s). Here is my
Please check the test cases in the source tree. They help a little bit.
#include stdlib.h
#include stdio.h
exec sql include sqlca;
int main( int argc, char *argv[] ) {
exec sql whenever sqlerror sqlprint;
exec sql connect tootle;
The correct syntax is
exec sql connect to tootle;
exit( 0 );
exec sql disconnect sprawlsr;
Sorry, I do not understand that line. At first your program will never
disconnect from that database since it exists before it can execute that
statement. And second you never connected to sprawlsr so how can you
dissconnect?
}
And here is what I get back:
sql error Could not connect to database DEFAULT in line 25.
What am I doing wrong? Yes, the database does exist as tootle.
Yup, that's one of those Oracle compatibility hacks. If you use connect
without 'to' ecpg expects the following term to a oracle like user
specification.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
Re: [GENERAL] PostgreSQL article in LinuxWorld
On Wed, May 31, 2000 at 04:27:24PM -0400, Bruce Momjian wrote: http://www.linuxworld.com/linuxworld/lw-2000-05/lw-05-database.html It mentions PostgreSQL. I was interviewed for the article. Nice article, but the author should get some facst straight. Postgres was never sold as Ingres. :-) Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
Re: [GENERAL] Performance
On Tue, May 16, 2000 at 10:52:33PM +0200, SimeX wrote: ... Argg, You should read a database's book. I wonder what you saw on this table definition that warrants such a response. Since I did not read the original mail maybe you just didn't quote the relevant parts, so I'm curious. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL!
