I asked the list to update the webite and add link for farsi FAQ.
I dont know why web site maintainer has not fixed it.
Is it necessary to update farsi FAQ for new version of postgresql so that it can be added in web site?
With Regards,--taghi
Do you Yahoo!?
Yahoo! Mail - Find what you need w
Patch applied.
Tom Lane wrote:
One objection: I think the GiST amproc numbers (GIST_CONSISTENT_PROC
and friends) *are* part of the API and should be in the public header,
even if they happen not to be used by any C code at the moment.
Ok, I've moved these back to gist.h
GISTNStrategies seems inhere
Neil Conway <[EMAIL PROTECTED]> writes:
> This patch moves GiST implementation details from gist.h into a new
> header file, gist_private.h.
Sounds reasonable. The other index AMs could possibly benefit from the
same thing --- in particular I believe nbtree.h is included by quite a
lot of places
This patch moves GiST implementation details from gist.h into a new
header file, gist_private.h. gist.h should only contain APIs that are
exposed to clients writing GiST extensions -- where possible we should
avoid backward-incompatible changes to those APIs, so it makes sense to
keep that API
Patch applied.
Tom Lane wrote:
Neil Conway <[EMAIL PROTECTED]> writes:
BTW, this idiom occurs a few times:
if (BufferIsValid(buf))
{
ReleaseBuffer(buf);
buf = InvalidBuffer;
}
I'd leave it as-is; ISTM to be more easily understandable than the
alternatives you suggest.
Tom Lane wrote:
> Bruce Momjian writes:
> >> What was the point again?
>
> > Simon said that the EXECUTE is pretty useless for debugging unless we
> > show the prepare query. His patch shows the prepare query for
> > client-side prepare, but not for server side when using the
> > PREPARE/EXECUTE
Bruce Momjian writes:
>> What was the point again?
> Simon said that the EXECUTE is pretty useless for debugging unless we
> show the prepare query. His patch shows the prepare query for
> client-side prepare, but not for server side when using the
> PREPARE/EXECUTE commands --- seems we should
Greg Sabino Mullane wrote:
Attached are some tab-completion enhancements for psql.
Barring any objections I'll apply this later today or tomorrow.
-Neil
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Attached are some tab-completion enhancements for psql. In rough order,
they are:
* Made DELETE into "DELETE FROM"
* Moved ANALZYE to the end of the list to ease EXPLAIN / VACUUM
conflicts
* Removed the ANALYZE xx semicolon completion: we don'
Tom Lane wrote:
> Bruce Momjian writes:
> > a null for the prepare string. Also, rather than change the API for
> > pg_parse_query(), I use a global variable that I check after the
> > function call.
>
> This is horribly ugly and will doubtless lead to pfree crashes. What
Agreed, it needs work
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tom Lane wrote:
> Bruce Momjian writes:
> > a null for the prepare string. Also, rather than change the API for
> > pg_parse_query(), I use a global variable that I check after the
> > function call.
>
> This is horribly ugly and will doubtless lead to pfree crashes. What
> was the point again?
Bruce Momjian writes:
> a null for the prepare string. Also, rather than change the API for
> pg_parse_query(), I use a global variable that I check after the
> function call.
This is horribly ugly and will doubtless lead to pfree crashes. What
was the point again?
rega
OK, new patch. I used portal->sourceText as Tom suggested, and checked
for NULL before printing. I put the original query in brackets in the
log output, patch attached.
I would like to also do this for server-side EXECUTE. I am have
attached a second version that does it by using the existing
Neil Conway <[EMAIL PROTECTED]> writes:
> ... replaces two ReleaseBuffer() + ReadBuffer() pairs with
> ReleaseAndReadBuffer(). (Is this still worth doing? It seems it no
> longer saves a lock acquire/release, but perhaps it will again be a win
> in some future version of the bufmgr...)
I think
Neil Conway wrote:
This is an updated version of the GiST patch I posted a few months ago.
Attached is a revised version. This update fixes some newly-added bugs
in mark and restore (I forgot to save and restore the current buffer),
and replaces two ReleaseBuffer() + ReadBuffer() pairs with
Rele
(BTom Lane <[EMAIL PROTECTED]> writes:
(B> a_ogawa <[EMAIL PROTECTED]> writes:
(B> > It is a reasonable idea. However, the majority part of MemSet was not
(B> > able to be avoided by this idea. Because the per-tuple contexts are used
(B> > at the early stage of executor.
(B>
(B> Drat. Well
would you please fix it, why farsi faq is not in web site?With Regards,--taghi
Discover Yahoo!
Have fun online with music videos, cool games, IM & more. Check it out!
On Thu, 2005-05-12 at 11:26 -0400, Tom Lane wrote:
> I have another idea though: in the case you are looking at, I think
> that the context in question never gets any allocations at all, which
> means its blocks list stays null. We could move the MemSet inside the
> "if (blocks)" test --- if ther
19 matches
Mail list logo
