line switch is needed.
After all you could run ecpg with "-o -" and make it output to stdout.
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 Fi
er versions around? Yes, you did a
rebuild, but still.
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!
--
se prototypes?
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
ned but not used
> preproc.y: At top level:
> pgc.c:3818: warning: `yy_flex_realloc' defined but not used
These don't appear with my flex version.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo: mi
messages.
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)---
are still
coming in. But then I might have gotten a false impression.
Anyway, if the release is still far enough away, I would like to commit
my changes too.
Comments?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/
t!
There were some with platforms I didn't test on, but hopefully they are
fixed now. There is one more problem with the threading tests that are
run even if threading is not activated. Will look into this later.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes
--
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
r)/parse.h: gram.y
So except for the different naming it's the same. However, we haven't
had that problem with the backend so far, or did we?
What do I fail to see?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304,
If so, 1 and 2 are not
> correct fixes.
Sorry, I don't get this. What exactly are you talking about here?
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 4
seems to be absolutely superfluous, so I removed it.
Fixed in CVS head.
Thanks for the report.
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
compile on
Windows.
Michael
P.S.: Is there some documentation available on how to set up a Windows
build system? Takes less time when you know all software to install
beforehand and if you get this software at all.
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Mi
7;s breaking
the compiler.
> Seems like the entire definition of the struct is commented out?
This is indeed the problem. I attach the diff so you see that instead of
typedef'ing the struct it just comments it out.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes
gt; [4] stmtCacheEntries in ecpg/ecpglib/prepare.c:
> Reading/writing are not safe in ECPGauto_prepare().
This also doesn't look like a dangerous bug, but it's still not working
as it should. I'd say let's fix them all.
Michael
--
Michael Meskes
Email: Michael at
option
"-c" when compiling array_of_struct.pgc? It is listed that way in the
Makefile, however lacking this option should generate exactly the file
you sent.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM/Yahoo:
;
Not really, it looks like you're using "-c" on this file too. This one,
however, is supposed to be compiled without "-c".
> diff of the .c file is:
> 17c17
> < #line 1 "./../regression.h"
> ---
> > #line 1 "regression.h"
Wonder where
ll now so can't read
> the code - how do I determine which files need it?
It's only array_of_struct that needs this option. I think one test for
this special option should be sufficient.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|N
Who's in charge of editing this site? I just thought about adding my IRC
nick but the page is locked.
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
On Tue, Oct 02, 2007 at 02:21:02PM +0200, Stefan Kaltenbrunner wrote:
> as referenced on the frontpage:
>
> http://developer.postgresql.org/index.php/Editing_Guidelines
Argh! Being able to read definitely helps. Sorry for this.
Thanks Stefan.
Michael
--
Michael Meskes
Email: Micha
hreading. Will fix
asap.
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!
---(en
problems. Some
reports look ambiguous, so we need to wait.
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 P
additional option "-r questionmarks" to ecpg. Here's
the line from the normal Makefile:
$(ECPG) -r questionmarks -o $@ -I$(srcdir) $<
autoprep also needs an additional parameter. It's "-r prepare". And
again, here's the line:
$(ECPG) -r prepare -o $@ -I$(srcdir) $<
On Wed, Oct 03, 2007 at 02:34:59PM +0200, Magnus Hagander wrote:
> With that, all the ECPG regression tests now pass on MSVC builds.
Great!
Thanks a lot for your help Magnus.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140
On Thu, Oct 04, 2007 at 12:47:13AM -0400, Tom Lane wrote:
> Buildfarm member brown_bat (cygwin/gcc) still isn't happy:
> ...
Just committed a patch that hopefully solves this. Kind of surprises me
that this only occurs on cygwin.
Michael
--
Michael Meskes
Email: Michael at Fam-Me
BPGTYPES' >> libpgtypesdll.def
> echo 'EXPORTS' >> libpgtypesdll.def
> ...
> I wonder why the dlltool failure is not causing the build to fail
> immediately?
These lines are simply copied from libpq/Makefile but ddltool does not
complain while working on libpq. Any id
paces ... However I'm thinking that maybe
> it's better to change the sed line to consider both spaces and tabs in
> the regex.
I'm not sure how portable sed scripts containing tabs are, so I simply
replaced the tabs in those export files by white spaces. Hopefully
that'
e. Do we need it in libpq? Or else we could remove if
everywhere. Maybe someone's working on 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
y working on all other platforms a and is also compilable, but not
working in some/most cases, on Windows.
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 4
ich comments?
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: explain analyze is your friend
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)
n.l,
> sharing parser.c isn't much of a savings anyway.
For the time being, no, you're 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 S
an gram.y) and see what ecpg
needs and what not.
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!
--
x27;m not aware
of. Or was the code incorrectly used?
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 VfL Borussia! Use Debian GNU/Linux! Use PostgreSQL!
check_string_escape_warning() btw. are only called in mode xe. Seems to
me that both are never called, or what am I missing?
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
pointing me into the right
direction.
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!
--
lect 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
-
- Forwarded message from Mike Aubury <[EMAIL PROTECTED]> -
From: Mike Aubury <[EMAIL PROTECTED]>
To: Michael Meskes <[EMAIL PROTECTED]>
Subject: PGconn ?
Date: Wed, 30 Jan 2008 19:51:00 +
Any chance of adding this (or something similar) for the next RC?
Am I correct to assume that HEAD is still 8.3? Or in other words, the bug
fixes I just committed are they part of the 8.3 branch automatically and
thus be included in 8.3.1?
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304, AIM
chael
--
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)--
est problem, but a user using
the Informix compatibility feature on NetBSD will run into the same
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 S
less what you suggest.
Instead of #define'ing dtimt_t I let ecpg handle this. this actually is
code that was part of ecpg before I just put it back in and changed the
other header files some. Let's see if this helps.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael a
ething?
Besides I don't think it's a good idea to create a local variable overriding a
global one with the same name.
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: 179
t; Is it acceptable?
Yes sure.
I changed some small parts of your patch (see above) and will commit in a few
minutes. Just running regression tests.
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|P
epare test out of the parser.
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! Forca Bar
preprocessor
I changed this to use the already existing _ECPG_INFORMIX_H define.
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: michaelmesk
does use int64. However, ecpg uses HAVE_LONG_LONG_INT64 to decide whether
it's datatype ECPGt_long_long exists. I changed the patch to use the same
define as usual.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Mes
that I committed Zoltan's patch.
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! Forca Ba
On Wed, Jan 06, 2010 at 09:42:06AM +0100, Boszormenyi Zoltan wrote:
> Attached. Passes "make check" here on 32-bit and
> 64-bit builds under Fedora 9/x86-64.
Applied.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at Bo
On Wed, Jan 06, 2010 at 03:36:39PM -0500, Tom Lane wrote:
> > BUG #5236: Aparent bug in ecpg
> > http://archives.postgresql.org/pgsql-bugs/2009-12/msg00078.php
>
> Michael needs to look at that one.
I'm waiting for a reproducable test case.
Michael
--
Michael Meskes
Mi
But I guess
we could get all this from the cvs log too. The file has been there for a long
time.
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:
advice is to
> drop the Changelog file and be sure you describe changes appropriately
> in the commit messages.
You definitely get a +1 from me as this file only means additional work that
tends to be forgotten. And yes, it does not have any information that the CVS
log doesn't hav
ic_type again we would run into this
situation even earlier as the return value then is stort in a short int because
that's what the other sqlda deffinitions use too. Therefore we have to make
sure we do not cross the short max. I'm glad at least one compiler caught this.
Michael
--
Michae
tement cache for auto-prepared
statements even if the statement is not auto prepared? Some statements are not
profiled, how did you decide which one to do?
There is no test case.
Before looking into it in detail I think we should first figure out if this
feature really has a benefit.
Michael
--
Michae
On Wed, Jan 13, 2010 at 09:22:28AM +0100, Boszormenyi Zoltan wrote:
> I think it's best to assume a string. ecpg_set_{compat,native}_sqlda()
> uses the defailt case in that meaning anyway.
Okay, applied as you send it.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michae
ch to make it
into our source tree there should be an advantage fore more people.
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, J
On Fri, Jan 15, 2010 at 01:16:18PM +0100, Boszormenyi Zoltan wrote:
> Please, also add this small change that adds ecpg_raise()
> calls to ECPGdescribe() to return the proper sqlca error
> in error paths for:
> ...
Done.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Micha
atched system. Is it an additional test that just happened to
be included here?
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 michaelmeske
it be "const char *" ?
> If the argument has a const, callers assume that they can pass
> a not-strdup'ed string as the argument.
Valid point, I can see no reason for not making this a "const char *". So let's
try.
Michael
--
Michael Meskes
Michael at
for select * from a1", ECPGt_EOIT,
> + ECPGt_int,&(myvar.id),(long)1,(long)1,sizeof(int),
> ...
Why does the preproc spit out ECPGset_var's but no ECPGget_var's in this test
case?
Michael
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot
iler, so ECPGset_var() is always used.
This shows some well thought implementation. But what I was wondering about was
why this is used as test case. While I see the need to test this part of ecpg I
thought this test case was added because it showed a problem without your
changes.
Michael
--
Michael Me
em? Isn't it hidden now by the new functionality of not
spitting out ECPGget_var's?
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 michael
(if accepted) is a unified one, it would show
> the problem for native mode as well.
That was my feeling too and the reason for these questions. Again, this has
nothing to do with the feature you implemented, it was just about this special
test.
Michael
--
Michael Meskes
Michael at Fam-Meskes
> Should I send you a new patch without this regression test
> or do you delete it before applying the patch?
Na, I will just remove it, no need to worry.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Mes
ded but I didn't notice.
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
Zoltan, could you please look into this:
http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=dugong&dt=2010-01-26%2011:05:01 ?
Apparently dugong creates the ECPGset_var statements in a different order than
the other archs.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes
On Fri, Jan 29, 2010 at 06:32:20AM +0100, Boszormenyi Zoltan wrote:
> I know. Patches were already posted for that,
> waiting for Michael to review and apply it.
Just came back from another trip. Patch works on my system, so I committed it.
Michael
--
Michael Meskes
Michael at Fam-Mesk
o our CVS or into its own accessible source archive. It
doesn't make sense IMO to bloat the patch with code not needed for the
backend functionality at this point in time.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
ICQ: 179140304
On Sat, Aug 02, 2008 at 12:33:38AM -0400, Tom Lane wrote:
> grammar. Right now the situation is that Michael Meskes makes a manual
> cleanup pass every so often :-(. I would like to see that get automated
> sooner rather than later, but in the near term it is not the
I received a very
ema
> [22245]: ecpg_check_PQresult line 13256: Error: ERROR: syntax error at or
> near "$1"
> LINE 1: set search_path to $1
Without checking the sources it seems as if PQexecParams is not able to handle
a parameter in a set command. Can anyone confirm this?
Michael
--
Michael Mesk
7: RESULT: 1966-01-17 offset: -1; array: yes
[NO_PID]: sqlca: code: 0, state: 0
[NO_PID]: ecpg_get_data on line 37: RESULT: 2000-07-12 17:34:29.140787 offset:
-1; array: yes
[NO_PID]: sqlca: code: 0, state: 0
...
What do I miss here?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, M
se it is new.
Is this understandable? :-)
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: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF
mestamp 'official' format, i mean
> timestamp expressed as number of microseconds since
> 2000-01-01. But of course, it only deserves this name 'official' if it is
> guaranteed to stay the same across postgresql versions and
> platforms
You shouldn't rely on this. Ag
y better for the
> purpose.
Well I think it's at least readable. Problem with your approach is that both
Mike and I feel more comfortable with awk at the moment. If a2p produces a
working perl script, that doesn't seem to be a problem IMO as we could maintain
the awk script but deliver
o contact?
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: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers! Use Debian GNU/Linux! Use Po
ference any more.
To test you need an up-to-date HEAD because ecpglib didn't like an additional
blank.
Comments/improvements/bug reports welcome.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debi
ert something before that second rule, it won't work anymore.
> FWIW, I'm also pretty firmly convinced that awk was the wrong choice for
> implementing this script...
Well, I work with what I have. What language would you prefer? And btw what
makes you so convinced?
Michael
--
Michae
So yes, I'd remove Iconst/Sconst.
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: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL Borussia! Go SF 49ers
perl hacker
can beautify the script quite a bit.
Anyway, it does work, regression tests run through (need to update expected
results though). So guys, now's the time to test before it makes it into the
archive. :-)
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meske
e all rules use the same
symbol which will make gram.y be consequent in its symbol usage and simplify my
work to generate the ecpg parser out of an unchanged gram.y at the same time.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFa
gt; preproc.y and compare the
result to pgsql/src/interfaces/ecpg/preproc/preproc.y. Both files should be
identical.
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,
mixed-case spelling looks like
a non-terminal and at some point people will spend time looking to the rules
defining these non-terminals.
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
ier into each file that
> will be added to CVS?
Definitely.
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: michaelmeskes, Jabber: [EMAIL PROTECTED]
Go VfL
pg/pgtypeslib/dt.h. The numbers should match
IMO.
Also one files seems to be missing, there are no changes to
test/expected/pgtypeslib-dt_test.c in the patch, but when changing dt_test.pgc
this file should be changed too.
Could you add this to your work too?
Michael
--
Michael Meskes
Michael at Fa
Hi,
since my last email seems to have disappeared, here we go again. Here's my
current patch that includes the changes to the build system. Thanks to Magnus
for the Windows part.
Comments anyone?
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Ne
n CVS.
That's what I did first, but Magnus had a good reasoning to not keep preproc.y
if we keep preproc.c in our tarball. And I agreed that there doesn't seem to be
an advantage.
Michael
--
Michael Meskes
Email: Michael at Fam-Meskes dot De
ICQ: 179140304, AIM/Yahoo: michaelmeskes, Ja
On Thu, Nov 13, 2008 at 03:57:49PM -0500, Tom Lane wrote:
> Michael Meskes <[EMAIL PROTECTED]> writes:
> > That's what I did first, but Magnus had a good reasoning to not keep
> > preproc.y
> > if we keep preproc.c in our tarball. And I agreed that there doesn&#x
dy committed the new files, so the patch is way smaller.
However, the new files are not used without the attached changes to the build
system.
Does anyone see a problem with these changes? Or else I will commit.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|
> the script uses it at all, or does it?
The new version does. I need to tell the script where to find the other files
in a VPATH build system.
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|Post
a good idea to list preproc.c's antecedent as
> $(srcdir)/preproc.y not just preproc.y. Also, you'll need to add
> preproc.y to .cvsignore.
Added.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meske
'm correctly identifying
> the corresponding code in 8.3, it has a semicolon where expected.
No, not that old. These rules were introduced at some point after 8.3 was
released, so no biggy here. This just meant that we went weeks without any
system complaining.
Michael
--
Michael Meskes
Micha
On Thu, Nov 20, 2008 at 05:07:40PM -0800, Ron Mayer wrote:
> Got it.
> Patch attached.
Looks reasonable to me.
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: 17914030
On Wed, Nov 26, 2008 at 09:31:48AM -0500, Tom Lane wrote:
> Michael, since that's ecpg code, please take charge of committing it
> if you want it.
Okay, done. I wasn't sure whether this was related to a backend patch that was
still under review.
Michael
--
Michael Meskes
Micha
inGW which is outdated, so don't be surprised if the regression tests
fail. Alternatively you could check in the file as
.../ecpg/test/expected/connect-test1-minGW32.stderr.
Thanks.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at Bor
re's the lexer rule:
:{identifier}((("->"|\.){identifier})|(\[{array}\]))*
No space possible between ":" and {identifier}.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFan dot De, Meskes at (Debi
end me a backtrace? I guess this has to be debugged
so we find out what's going wrong.
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: michaelmes
On Sun, Dec 14, 2008 at 11:36:21AM -0500, Andrew Dunstan wrote:
> See below
> ...
Thanks. The backtrace is kind of strange, but I might have found it. Could you
please update from CVS and re-run?
Thanks again.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes d
s implemented it was taken out of "make
check" because it requires a tcp connection, so you have to run "make checktcp"
instead. But if noone runs this, we could drop it.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at Bo
s it doesn't here. Could you please check this by
checking out the changes, re-running "make checktcp" and checking whether the
regression.diffs file changes?
Thanks
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Michael at BorussiaFa
(res_str, " ");
> + if (strlen(str1) != 0 && strlen(str2) != 0)
> + strcat(res_str, " ");
> strcat(res_str, str2);
> free(str1);
> free(str2);
> return(res_str);
> }
Hey, good idea, will add this too
was a test that expected the blank and thus looked into $1[1]
instead of $1[0]. :-)
I hope I found all of these.
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
201 - 300 of 652 matches
Mail list logo
