Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
Patch attached. Also adds a malloc() check that Neil wanted.
Er, what on God's green earth is elog.c doing malloc'ing stuff at all?
This should be a palloc in the ErrorContext; that's what it's for.
As is, this code is guaranteed
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Patch attached. Also adds a malloc() check that Neil wanted.
Er, what on God's green earth is elog.c doing malloc'ing stuff at all?
This should be a palloc in the ErrorContext; that's what it's for.
As is, this code is guaranteed to fail under out-of-me
Attached is a proposed patch that fixes the
cursor-position-in-CREATE-FUNCTION issue per my earlier suggestion.
Since I complained that your proposal was too grotty, it's only fair to
throw this out to let people take potshots at it ;-). The main
grottiness here is providing access to the executi
OK, all added to CVS head. Thanks.
---
Larry Rosenman wrote:
-- Start of PGP signed section.
> Here is a patch for the UnixWare thread stuff (template only, not
> initdb), and to the test_fsync makefile to remove a gcc'ism:
Patch attached. Also adds a malloc() check that Neil wanted.
cheers
andrew
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
*sigh*
my local (linux) man for gettimeofday says this:
struct timeval {
time_t tv_sec;/* seconds */
Here is a patch for the UnixWare thread stuff (template only, not
initdb), and to the test_fsync makefile to remove a gcc'ism:
Index: src/template/unixware
===
RCS file: /projects/cvsroot/pgsql-server/src/template/unixware,v
retrieving
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> But it cannot (easily) match it up with the *original input*
> Sure. Even the parser in the backend cannot do it, that's the problem!;-)
We *can* do it, it's just a matter of the pain level. For instance we
could have the main lexer save aside an indi
Dear Tom,
> > Any GUI can take advantage of the returned string to show it in a window
> > with fancy colors and do any hilighting around the position.
>
> But it cannot (easily) match it up with the *original input*
Sure. Even the parser in the backend cannot do it, that's the problem!;-)
> an
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> Moreover, I don't like the proposed protocol change anyway. This
>> approach only solves the problem for psql-like error reporting, namely
>> clients that are going to regurgitate a string in their error message
>> and aren't very picky about whether th
Dear Tom,
> > Please find attached a patch to fix the "CREATE FUNCTION" syntax error
> > position bug I reported a few days ago.
>
> This strikes me as much too intrusive to be worthwhile ... the problem
> is simply not important enough to justify a protocol change.
Then I can suggest to happen
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Please find attached a patch to fix the "CREATE FUNCTION" syntax error
> position bug I reported a few days ago.
This strikes me as much too intrusive to be worthwhile ... the problem
is simply not important enough to justify a protocol change. Moreove
Dear patchers,
Please find attached a patch to fix the "CREATE FUNCTION" syntax error
position bug I reported a few days ago.
As the exact query being processed in only known to the backend (it may be
the initial query, it may be a subset of the initial query, it may be some
generated query?),
12 matches
Mail list logo
