Joe Conway wrote:
> Here is a revised patch for a sample C function returning setof
> composite. (Same comments as last time -- It is a clone of SHOW ALL as
> an SRF. For the moment, the function is implemented as contrib/showguc,
> although a few minor changes to guc.c and guc.h were required
Here is a revised patch for a sample C function returning setof
composite. (Same comments as last time -- It is a clone of SHOW ALL as
an SRF. For the moment, the function is implemented as contrib/showguc,
although a few minor changes to guc.c and guc.h were required to support
it.)
This ver
> Um ... what's the point? Isn't this always the same as the percentage
> for the underlying table?
Sure. In my understanding, unlike tables "free/reusable space" is
actually not reused in index. pgstatindex would be usefull to judge if
REINDEX is needed by showing the growth of physical length
Ian Barwick <[EMAIL PROTECTED]> writes:
> CREATE OR REPLACE FUNCTION public.first_visible_namespace(name)
> RETURNS oid
> AS
> 'SELECT n.oid
> FROM pg_namespace n, pg_class c, public.current_schemas_setof() cs
> WHERE c.relname=3D $1
> AND c.relnamespace=3Dn.oid
> AND
Tatsuo Ishii <[EMAIL PROTECTED]> writes:
> Here is a new contrib function called "pgstatindex", similar to
> pgstattuple but different in that it returns the percentage of the
> dead tuples of an index. I am posting this for review purpose.
Um ... what's the point? Isn't this always the same as
On Wednesday 01 May 2002 06:38, Tom Lane wrote:
> Ian Barwick <[EMAIL PROTECTED]> writes:
> > How can I restrict the query to the schemas in the
> > current search path, i.e. the schema names returned
> > by SELECT current_schemas() ?
>
> Well, this is the issue open for public discussion.
>
> We
On Sunday 26 May 2002 17:58, Tom Lane wrote:
(...)
> If anyone does someday resurrect fjoin-like functionality, a reasonable
> SQL-style syntax for invoking it would be
>
> SELECT (bar(1)).*;
>
> which would still leave us wanting to raise an error if you just write
> "SELECT bar(1)".
The r
Hi every one.
I just moved (at last!) to 7.2.1. Works like a charm...
I'm suprised though by the number of WAL files.
I have 8 files where postgresql.conf says WAL_FILES=4.
What did I miss ? (I have no outstanding transaction)
FWIW, t's on UW711.
Regards,
--
Olivier PRENANT
Joe Conway <[EMAIL PROTECTED]> writes:
> This is an illustration of why the expression SRF API isn't very useful
> for returning composite types ;)
> The number is actually a pointer to the result row. There is no way
> under the expression API to get at the individual columns directly.
You can
Neil Conway <[EMAIL PROTECTED]> writes:
> I can understand not allowing COPY FROM to target a view
> (or at least, a view without an insertion rule defined) --
> but is there a similar reason for disallowing copying data
> out of a view?
Allowing either would take COPY out of the realm of utility
Ian Barwick wrote:
> but also this:
>
> func_test=# select bar(1);
> bar
> ---
> 139059784
> (1 row)
>
> What is this number? It often varies from query to query.
> Possibly an error-in-disguise because of something to do
> with the calling context?
This is an illustration of w
Just tested with 7.2.1. It works. We have one more patch (for rtree_gist)
to submit before 7.2.2 release.
Oleg
On Sun, 26 May 2002, Teodor Sigaev wrote:
> > Yeah, but the update case is inserting more entries into the index.
> > I'm wondering if that causes the index scan's state to get
> Yeah, but the update case is inserting more entries into the index.
> I'm wondering if that causes the index scan's state to get corrupted
> so that it misses scanning some entries. btree has a carefully designed
> algorithm to cope with this, but I have no idea how gist manages it.
Thank you
13 matches
Mail list logo
