[INTERFACES] ECPG Documentation Improvement
Satoshi Nagayasu
I'm trying to improve the ECPG documents for the ECPG application
developrs, because some of my clients want more detailed information
when they develop (or migrate) an embeded SQL applications.
Of course, I want to contribute this work to the official manual.
So I have one thing to introduce to you, and thing to ask you.
At first, I've done writing ECPG directives.
I think it could be useful for the ECPG application developers,
similar to the SQL reference section in the official manual.
ecpgdocs @ GoogleCode (I'm working here.)
http://code.google.com/p/ecpgdocs/
ecpgdocs downloads (You can find the current document.)
http://code.google.com/p/ecpgdocs/downloads/list?deleted=1&ts=1276763948
However, I'm not familiar with ECPG details or internals,
so here is one asking, I hope someone to review my documents
and give some feedback to me.
Feedbacks which I'm expecting are:
- Is this document useful?
- Missing directives.
- Missing or wrong synopsis.
- More appropriate descriptions on parameters or examples.
- How to contribute this to the official manual.
- Correcting English. (sorry for my poor English.)
- etc...
Honestly, I'm not familiar with the documentation acceptance/review process,
so any advice and/or comments are welcome.
Regards,
--
NAGAYASU Satoshi <satoshi....@gmail.com>
--
Sent via pgsql-interfaces mailing list (pgsql-in...@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-interfaces
Satoshi Nagayasu
Thanks for the comments.
On 2010/06/18 4:27, Mark Richardson wrote:
> Here's some info that I found...
> For conversion of Sybase .pc files to postgres .pgc files, you have to
> parse the .pc file and change from sybase format to postgres format. We
> used a simple script but here's what we changed the following (sybase is
> first column, postgres is second - quotes are used just to indicate the
> entire string, you don't need them in the search/replace)
As you mentioned, I feel the embeded SQL technology has
many compatibility challenges to port applications.
So now I'm thinking how we can hold such compatibility
tips or tricks in the manual.
I'm interested in having the "Compatibility" section
to gather compatibility information which depends on
several RDBMSes, like "Informix compatibility mode" section.
If it could be helpful, I will try it.
I have to work on SQLDA stuffs to clarify its usage,
because I heard that the PostgreSQL SQLDA is not compatible
with Oracle's one, it's compatible with others
(DB2? Sorry if it's wrong).
Thus, the PostgreSQL ECPG is currently a mixture of several
RDBMSes, so I want to clarify the spec and its compatibility.
I guess it could be helpful for application developers. :)
> I also looked up the boolean type for ecpg, the problem is in postgres
> 8.0.1 (maybe later)
> postgresql/src/interfaces/ecpglib/execute.c line 775 (case ECPGt_bool)
> the line was
I will check this, and modify the manual if we need.
Michael Meskes
> Here's some info that I found...
Just a few questions to make sure I understand your correctly.
> "INCLUDE SQLCA" "INCLUDE sqlca"
So it's just the case of the name? We could lowercase the name in ecpg or
simply install a link SQLCA.h->sqlca.h. So there is no need to change that
anymore. Thoughts?
> "SQLCA" "struct sqlca_t"
struct sqlca_t is defined in sqlca.h but I cannot see a reason why it is used
in client code. sqlca.h also defines sqlca, so it might be a case problem
again. Does it still work if you replace "SQLCA" by "sqlca"?
> "CS_BIT" "bool"
> "CS_CHAR" "char"
> "CS_INT" "int"
> "CS_TINYINT" "short"
> "CS_SMALLINT" "short"
> "CS_REAL" "float"
> "CS_FLOAT" "double"
> "CS_LONG_LONG" "long long"
> "CS_LONG" "int"
> "CS_BINARY" "char"
> "CS_TEXT" "char"
> "ISOLATION LEVEL 0" "ISOLATION LEVEL READ COMMITTED"
> "ISOLATION LEVEL 1" "ISOLATION LEVEL READ COMMITTED"
> "ISOLATION LEVEL 2" "ISOLATION LEVEL SERIALIZABLE"
We could add this in a compatibility level.
> "CHAINED OFF" "CHAINED TO OFF"
> "CHAINED ON" "CHAINED TO ON"
These maybe too.
> I also looked up the boolean type for ecpg, the problem is in postgres 8.0.1 (maybe later)
> postgresql/src/interfaces/ecpglib/execute.c line 775 (case ECPGt_bool)
> the line was
> sprintf(mallocedval, "'%c'", (*((char *) var->value)) ? 't' : 'f');
> changed it to
> sprintf(mallocedval, "'%c'", (*((char *) var->value)) ? '1' : '0');
It still uses 't' and 'f', so that's crying for the compatibility level too.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Michael Meskes
> How could we (re-)organize the document structure to eliminate such redundancy?
The document structure is not set in stone, if you deem it better to reorganize
it feel free to do so.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--
Lars Nordin
> Hi all,
>
> In past two months, I was working to improve the ecpg manual,
> and work for a draft of the new manual is now 90% finished.
> This document is getting very similar to the final edition,
> so I hope to introduce to you.
...
> Any feedback and comments would be appreciated.
Comparing the previous version to your draft, I have to say thanks a lot of
for the large amount work that you have put into the new document.
Michael Meskes
> I've been waiting for Michael to weigh in. But maybe he's not reading
> this thread?
Well he is, sort of. I've got quite a delay in handling/reading my emails due
to real life time constraints and upcoming trips, sorry.
I had a short look at the docs Satoshi-san put online and yes, I'm impressed.
However, I won't be able to proof read them before September. But given that
9.1 development is just starting I see no problem in putting the docs into the
archive be it cvs or git and improve if there if it really needs improvement.
In my short check I didn't see anything major that needed to be changed. This
of course implies that the new docs are available in a suitable format.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org
ICQ 179140304, AIM/Yahoo/Skype michaelmeskes, Jabber mes...@jabber.org
VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
--