On Mon, 05 Apr 2004 15:37:07 -0400, Tom Lane <[EMAIL PROTECTED]> wrote:
>I wouldn't bother with a GUC variable for the production patch.
Among other things the GUC variable will be thrown out for the final
version.
>> Once a block is selected for inspection, all tuples of this
>> block are access
Manfred Koizar <[EMAIL PROTECTED]> writes:
>>> Because I was afraid that method 1 might be too expensive in terms of
>>> CPU cycles, I implemented a small variation that skips tuples without
>>> checking them for visibility; this is sampling_method 2.
>>
>> And? Does it matter?
> There's a clear
Manfred Koizar <[EMAIL PROTECTED]> writes:
> The old sampling method is still there. I have added a GUC variable
> sampling_method to make testing and benchmarking easier.
I wouldn't bother with a GUC variable for the production patch.
> Once a block is selected for inspection, all tuples of thi
Dear Tom,
> No, just redefine "yyerror" as a macro that passes additional parameters.
Ok! That's just the kind of the hack-hook I was looking for!!
> > The terminals are not available, they must be kept separatly if you
> > want them. This can be done in yylex().
>
> We don't need them. Any a
Tom Lane wrote:
Fabien COELHO <[EMAIL PROTECTED]> writes:
(b) write a new "recursive descendant" parser, and drop "gram.y"
er, that's "recursive descent" :-)
Been there, done that, not impressed with the idea. There's a reason
why people invented parser generators...
Well, unless yo
Here is the first preview of the two-stage tuple sampling as discussed
on -hackers last week. It is for review only, please do not apply.
As I didn't have a current CVS checkout when I worked on the patch, it
is based on 7.4.2 sources. I hope this is ok for the purpose of
reviewing.
The old sam
Fabien COELHO <[EMAIL PROTECTED]> writes:
>> If you can think of a reasonable way to stop treating them as separate
>> tokens inside the grammar without altering the user-visible behavior,
>> I'm certainly interested.
> I join a small proof-of-concept patch to drop some tokens out of the
> parser.
As another teaching aid idea, is there something that would auto-format
queries to they are more readable?
---
Fabien COELHO wrote:
>
>
>
> Dear Tom,
>
> > No, just redefine "yyerror" as a macro that passes additional pa
> As another teaching aid idea, is there something that would auto-format
> queries to they are more readable?
Not that I know of. But I guess it must exist in some interface,
maybe with Oracle or DB2.
My emacs does seem to do that. It just put colors on keywords.
If I had to put it somewhere,
Dear Tom,
> No, just redefine "yyerror" as a macro that passes additional parameters.
Ok! That's just the kind of the hack-hook I was looking for!!
> > The terminals are not available, they must be kept separatly if you
> > want them. This can be done in yylex().
>
> We don't need them. Any
Greetings,
The attached patch adds some error-checking to the timestamp_recv
function so that it's not possible to put an invalid timestamp into a
timestamp column (hopefully). The check is done in basically the
exact same way the out-of-bounds check in timestamp2tm is done.
There's pro
Fabien COELHO <[EMAIL PROTECTED]> writes:
> Although I agree that it is "doable", I have stronger reserve than yours.
> Also, I do not find it an appealing solution to change "gram.c" a lot.
I was not proposing hand-editing gram.c after bison generates it,
if that's what you meant ;-). It seems h
Dear Tom,
First, thanks for the discussion about my "hint" infrastructure patch
submission. Whatever the opinion, it helps.
> We'd have to write our own version of bison's verbose-error code anyway,
> because the canned code doesn't support localization --- it uses
> hardwired strings for "expe
Am Samstag, 27. März 2004 22:18 schrieb Serguei Mokhov:
> These are for the HEAD:
>
> - updated libpq and psql for 7.5
> - initial cut on initdb
Installed.
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an ap
Am Samstag, 27. März 2004 22:40 schrieb Serguei Mokhov:
> Please include these updates for 7.3
Done.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
> [snip]
> #ifndef WIN32
> #define pgpipe(a) pipe(a)
> #define piperead(a,b,c) read(a,b,c)
> #define pipewrite(a,b,c)write(a,b,c)
> #else
> extern int pgpipe(int handles[2]);
> extern int piperead(a,b,c);
> extern int pipewrite(a,b,c);
> #endif
>
> And then
Am Samstag, 27. März 2004 18:59 schrieb Serguei Mokhov:
> These are translation updates for the 7.4.x branch.
> Please install.
Done.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.or
> > A thought about this - how about converting pgpiperead() and
> > pgpipewrite() into functions intead of macros (on win32 - still
> > redifining them on != win32), mimicking the behaviour of read() and
> > write()?
>
> And #def'ing them to be read + write under win32? Don't want
> to change
Am Montag, 29. März 2004 03:35 schrieb Serguei Mokhov:
> This should complete traslation updates for 7.3.
> Please install.
Done.
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Dear patchers,
Please find a small patch to fix the brain damage "century" and
"millennium" date part implementation in postgresql, both in the code and
the documentation, so that it conforms to the official definition. If you
do not agree with the official definition, please send your complaint
20 matches
Mail list logo
