On Sat, 31 Mar 2007 14:09, you wrote:
> FAST PostgreSQL wrote:
> >> Am Dienstag, 3. April 2007 20:33 schrieb FAST PostgreSQL:
> >>> Attached is the completed patch for the COPY-able sql log outputs.
> >>
> >> Could you please remove random whitespace changes from this patch?
> >
> > Done and attach
"Andrew - Supernews" <[EMAIL PROTECTED]> wrote:
> ITAGAKI> I think all "safe ASCII-supersets" encodings are comparable
> ITAGAKI> by bytes, not only UTF-8.
>
> This is false, particularly for EUC.
Umm, I see. I updated the optimization to be used only for UTF8 case.
I also added some inlining
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Here's the current version of the enums patch.
Applied with revisions --- some cosmetic, some not so much.
Attached is the patch-as-applied if you care to compare; feel free
to ask questions about anything not obvious.
regards, tom
Tom Lane wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Any page written during a backup has a backup block that would not be
>> removable by Koichi's tool, so yes, you'd still be safe.
>
> How does it know not to do that?
>
> regards, tom lane
>
> --
Tom Lane wrote:
OK, I give up. :) Why?
Because the whole point is that the type has to be known at parse time.
Oh, duh. :)
I've got it working with get_fn_expr_argtype and it seems fairly
reasonable.
Cool!
Thanks
Tom
---(end of broadcast)
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>>> ... could we
>>> have a special rule that would look for e.g. a regtype as the first
>>> parameter if the return type is generic and there are no generic parameters?
>>
>> I thought about that too but don't like it much. The problem
Tom Lane wrote:
The null Datum itself obviously doesn't carry that info, but the
expression tree does, and there are provisions for letting functions
retrieve that info --- see get_fn_expr_rettype and get_fn_expr_argtype.
Hmm. I vaguely remember that there was some feeling that the PLs
wouldn'
On Sun, 1 Apr 2007, Magnus Hagander wrote:
The data in pg_stat_bgwriter certainly doesn't update *during* a
checkpoint, if that's what you're saying.
Scratch previous message, replace with "dude ur code rulez!"
I was working on the assumption it was possible to get a partial result
because I
Tom Dunstan <[EMAIL PROTECTED]> writes:
> Andrew Dunstan wrote:
>> Tom Lane wrote:
>>> enum_first, enum_last: these return ANYENUM but violate the rule that
>>> a polymorphic-result function must have a polymorphic input argument
>>> from which the parser may deduce the actual output type.
>>
>> I
Simon Riggs wrote:
> I've sent through v10 of my patch for transaction guarantee = off twice
> now and it hasn't shown up on-list. I don't appear to be blocked, so I'm
> not sure what the problem is?
>
> Sent: 31 Mar 22:09 TZ+01:00
> Sent: 1 Apr 12:11 TZ+01:00
Did you by any chance send it in .t
Alvaro Herrera wrote:
Marko Kreen escribió:
On 3/30/07, Alvaro Herrera <[EMAIL PROTECTED]> wrote:
In any case it's not likely that there are going to be thousands of
prepared statements, so is this really an issue?
I think the issue is here that its very common thing to do,
so open-coding it
I've sent through v10 of my patch for transaction guarantee = off twice
now and it hasn't shown up on-list. I don't appear to be blocked, so I'm
not sure what the problem is?
Sent: 31 Mar 22:09 TZ+01:00
Sent: 1 Apr 12:11 TZ+01:00
--
Simon Riggs
EnterpriseDB http://www.enterpr
Cool patch.
On Wed, 2007-04-04 at 18:36 +, FAST PostgreSQL wrote:
> The planner has to be taught to treat a DELETE/UPDATE WHERE CURRENT OF
> as a TidScan. Currently it follows the sequential scan route and
> extracts the current tuple based on the cursor position from the
> portal.
So you let
text_enum: same problem as above, plus not acceptable to assume that it
gets the right enum OID, plus very definitely not acceptable to assume
that OID and typmod are the same size, plus I don't like the
undocumented kluge in getBaseTypeAndTypmod that is pretending to supply
the type OID for some
Andrew Dunstan wrote:
Tom Lane wrote:
enum_first, enum_last: these return ANYENUM but violate the rule that
a polymorphic-result function must have a polymorphic input argument
from which the parser may deduce the actual output type.
Is this a tragedy when the supplied parameter gives the resu
Tom Lane wrote:
enum_first, enum_last: these return ANYENUM but violate the rule that
a polymorphic-result function must have a polymorphic input argument
from which the parser may deduce the actual output type.
Is this a tragedy when the supplied parameter gives the result type
directly?
Greg Smith wrote:
> On Thu, 29 Mar 2007, Magnus Hagander wrote:
>
>> I've included a couple of more counters per ideas from Greg Smith in his
>> logging patch.
>
> I just submitted a patch that logs the remaining things of value from my
> original that couldn't be derived from the information you
17 matches
Mail list logo
