On 22.12.2010 09:25, Rob Wultsch wrote:
On Wed, Dec 22, 2010 at 12:15 AM, Heikki Linnakangas
wrote:
Hmm, innodb_autoextend_increment seems more like what we're discussing here
(http://dev.mysql.com/doc/refman/5.0/en/innodb-parameters.html#sysvar_innodb_autoextend_increment).
If I'm reading tha
On Wed, Dec 22, 2010 at 12:15 AM, Heikki Linnakangas
wrote:
> On 22.12.2010 03:45, Rob Wultsch wrote:
>>
>> On Tue, Dec 21, 2010 at 4:49 AM, Robert Haas
>> wrote:
>>>
>>> On Sun, Dec 19, 2010 at 1:10 PM, Jim Nasby wrote:
On Dec 19, 2010, at 1:10 AM, flyusa2010 fly wrote:
>
> Do
On 22.12.2010 02:56, Merlin Moncure wrote:
On Tue, Dec 21, 2010 at 7:45 PM, Tom Lane wrote:
Merlin Moncure writes:
Attached is an incomplete patch disabling hint bits based on compile
switch. ...
So far, at least doing pgbench runs and another test designed to
exercise clog lookups, the perfo
On 22.12.2010 03:45, Rob Wultsch wrote:
On Tue, Dec 21, 2010 at 4:49 AM, Robert Haas wrote:
On Sun, Dec 19, 2010 at 1:10 PM, Jim Nasby wrote:
On Dec 19, 2010, at 1:10 AM, flyusa2010 fly wrote:
Does postgres make an effort to create a file with physically continuous blocks?
AFAIK all files
On Wed, Dec 22, 2010 at 12:14 PM, Tom Lane wrote:
> Fujii Masao writes:
>> How about doing target != ALL test at the head for the most common case
>> (target == ALL)?
>
> That's an idea, but the test you propose implements it incorrectly.
Thanks! I revised the patch.
Regards,
--
Fujii Masao
N
On 2010-12-21 21:28, Andres Freund wrote:
On Tuesday 21 December 2010 20:25:16 Jesper Krogh wrote:
What have I missed in the logic?
A reproducible testcase ;-)
Yes, I did a complete dump/restore of the dataset and the numbers
looked like expected. So table bloat seems to be the
On Mon, Dec 20, 2010 at 00:39, Alex Hunsaker wrote:
> In further review over caffeine this morning I noticed there are a few
> places I missed: plperl_build_tuple_result(), plperl_modify_tuple()
> and Util.XS.
And here is v3, fixes the above and also makes sure to properly
encode/decode SPI argu
Robert Haas writes:
> On Tue, Dec 21, 2010 at 10:24 PM, Tom Lane wrote:
>> I'm fairly uncomfortable about the broad swath and low return of this
>> patch. Noah is assuming that none of these places are relying on
>> strncmp to stop short upon finding a null, and I don't believe that
>> that's a
Sushant Sinha writes:
> There is a bug in ts_rank_cd. It does not correctly give rank when the
> query lexeme is the first one in the tsvector.
Hmm ... I cannot reproduce the behavior you're complaining of.
You say
> select ts_rank_cd(to_tsvector('english', 'abc sdd'),
> plainto_tsquery('english
On Tue, Dec 21, 2010 at 11:12 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Dec 15, 2010 at 11:29 AM, Tom Lane wrote:
- Writeable CTEs - I think we need Tom to pick this one up.
- Fix snapshot taking inconsistencies - Ready for committer. Can any
committer pick this up?
>
>
On Tue, Dec 21, 2010 at 10:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> If it's done properly, I don't see how this would be a risk.
>
> I'm fairly uncomfortable about the broad swath and low return of this
> patch. Noah is assuming that none of these places are relying on
> strncmp to stop s
Robert Haas writes:
> If it's done properly, I don't see how this would be a risk.
I'm fairly uncomfortable about the broad swath and low return of this
patch. Noah is assuming that none of these places are relying on
strncmp to stop short upon finding a null, and I don't believe that
that's a s
On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas wrote:
> On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch wrote:
>> When the caller knows the smaller string length, memcmp and strncmp are
>> functionally equivalent. Since memcmp need not watch each byte for a NULL
>> terminator, it often compares a CPU
Fujii Masao writes:
> How about doing target != ALL test at the head for the most common case
> (target == ALL)?
That's an idea, but the test you propose implements it incorrectly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
On 22/12/10 13:56, Merlin Moncure wrote:
On Tue, Dec 21, 2010 at 7:45 PM, Tom Lane wrote:
@Mark: apparently the cvs server is behind git and there are some
recent changes to heapam.c that need more attention. I need to get
git going on my box, but try changing this:
if ((tuple->t_info
On Tue, Dec 21, 2010 at 9:01 PM, Robert Haas wrote:
> On Tue, Dec 21, 2010 at 8:29 PM, Gurjeet Singh
> wrote:
> > On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas
> wrote:
> >>
> >> On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch wrote:
> >> > When the caller knows the smaller string length, memcmp an
On Tue, Dec 21, 2010 at 8:29 PM, Gurjeet Singh wrote:
> On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas wrote:
>>
>> On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch wrote:
>> > When the caller knows the smaller string length, memcmp and strncmp are
>> > functionally equivalent. Since memcmp need not w
On Tue, Dec 21, 2010 at 4:49 AM, Robert Haas wrote:
> On Sun, Dec 19, 2010 at 1:10 PM, Jim Nasby wrote:
>> On Dec 19, 2010, at 1:10 AM, flyusa2010 fly wrote:
>>> Does postgres make an effort to create a file with physically continuous
>>> blocks?
>>
>> AFAIK all files are expanded as needed. I d
On Tue, Dec 21, 2010 at 6:24 PM, Robert Haas wrote:
> On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch wrote:
> > When the caller knows the smaller string length, memcmp and strncmp are
> > functionally equivalent. Since memcmp need not watch each byte for a
> NULL
> > terminator, it often compares
Excerpts from Quan Zongliang's message of mar dic 21 18:36:11 -0300 2010:
> On Mon, 29 Nov 2010 10:29:17 -0300
> Alvaro Herrera wrote:
>
> > I think the way this should work is that you call postmaster with a new
> > switch and it prints out its configuration, after reading the
> > appropriate c
On Sat, Dec 18, 2010 at 1:00 AM, Robert Haas wrote:
> On Fri, Dec 17, 2010 at 10:27 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> I think the attached might be a little tidier. Thoughts?
>>
>> I'm not really thrilled at the idea of calling
>> IsPostmasterChildWalSender for every child whether
On Tue, Dec 21, 2010 at 7:45 PM, Tom Lane wrote:
> Merlin Moncure writes:
>> Attached is an incomplete patch disabling hint bits based on compile
>> switch. ...
>> So far, at least doing pgbench runs and another test designed to
>> exercise clog lookups, the performance loss of always doing full
Merlin Moncure writes:
> Attached is an incomplete patch disabling hint bits based on compile
> switch. ...
> So far, at least doing pgbench runs and another test designed to
> exercise clog lookups, the performance loss of always doing full
> lookup hasn't materialized.
The standard pgbench test
On Tue, Dec 21, 2010 at 7:20 PM, Merlin Moncure wrote:
> On Tue, Dec 21, 2010 at 7:06 PM, Mark Kirkwood
> wrote:
>> On 22/12/10 13:05, Mark Kirkwood wrote:
>>>
>>> On 22/12/10 11:42, Merlin Moncure wrote:
Attached is an incomplete patch disabling hint bits based on compile
switch.
On Tue, Dec 21, 2010 at 7:06 PM, Mark Kirkwood
wrote:
> On 22/12/10 13:05, Mark Kirkwood wrote:
>>
>> On 22/12/10 11:42, Merlin Moncure wrote:
>>>
>>> Attached is an incomplete patch disabling hint bits based on compile
>>> switch. It's not complete, for example it's not reconciling some
>>> assu
On 22/12/10 13:05, Mark Kirkwood wrote:
On 22/12/10 11:42, Merlin Moncure wrote:
Attached is an incomplete patch disabling hint bits based on compile
switch. It's not complete, for example it's not reconciling some
assumptions in heapam.c that hint bits have been set in various
routines. Howev
On 22/12/10 11:42, Merlin Moncure wrote:
Attached is an incomplete patch disabling hint bits based on compile
switch. It's not complete, for example it's not reconciling some
assumptions in heapam.c that hint bits have been set in various
routines. However, it mostly passes regression and I dee
Merlin Moncure wrote:
> *) what's a good way to stress the clog severely? I'd like to pick
> a degenerate case to get a better idea of the way things stand
> without them.
The worst I can think of is a large database with a 90/10 mix of
reads to writes -- all short transactions. Maybe someone
Heikki Linnakangas writes:
> On 21.12.2010 21:25, Jesper Krogh wrote:
>> Or is a Bitmap Heap Scan simply 3 times faster than a Seq-scan for
>> visibillity-testing?
> It certainly shouldn't be.
>> What have I missed in the logic?
> Perhaps you have a lot of empty space or dead tuples that don't
On Mon, Dec 20, 2010 at 1:10 PM, Noah Misch wrote:
> When the caller knows the smaller string length, memcmp and strncmp are
> functionally equivalent. Since memcmp need not watch each byte for a NULL
> terminator, it often compares a CPU word at a time for better performance.
> The
> attached
On Tue, Dec 21, 2010 at 4:17 PM, Andreas Karlsson wrote:
> Found a couple of small typos in the comments of nodeWindowAgg.c when
> they refer to functions in nodeAgg.c. The pluralities of the function
> names (initialize_aggregates and advance_aggregates) are wrong. The
> reference to "finalize_ag
On Mon, 29 Nov 2010 10:29:17 -0300
Alvaro Herrera wrote:
> Excerpts from Quan Zongliang's message of sáb nov 27 06:03:12 -0300 2010:
> > Hi, all
> >
> > I created a pg_ctl patch to fix:
> > * BUG #5103: "pg_ctl -w (re)start" fails with custom unix_socket_directory
> > Allow pg_ctl to work prope
On Tue, Dec 21, 2010 at 4:57 PM, Pavel Golub wrote:
> Anyway I find such function usefull even though I still hadn't
> situation when it might be needed.
Yeah, I agree. I'm not sure we should add it to core, but it's
certainly just as useful as many things we have in contrib. I'll bet
it would
Hello.
Guys, guys! It was only a joke! :)
Please accept my appologies.
Anyway I find such function usefull even though I still hadn't
situation when it might be needed.
You wrote:
AD> On 12/21/2010 04:28 PM, Pavel Golub wrote:
>>
>> PS> * It isn't a typical and often request,
>> PS> * There
On 12/21/2010 04:28 PM, Pavel Golub wrote:
PS> * It isn't a typical and often request,
PS> * There are not hard breaks for custom implementation,
PS> * You can use plperu or plpython based solutions,
PS> * It's not part of ANSI SQL
But MySQL has such function. What's wrong with us? ;)
On Tue, Dec 21, 2010 at 11:28:17PM +0200, Pavel Golub wrote:
> Hello, Pavel.
>
> You wrote:
>
> PS> Hello
>
> PS> Dne 21. prosince 2010 21:11 Tom Mudru??ka
> napsal(a):
> >>
> >> Thx for you answers :-)
> >> Well... i know that i can write my own plugin and i am familiar with C so
> >> thi
Hello, Pavel.
You wrote:
PS> Hello
PS> Dne 21. prosince 2010 21:11 Tomáš Mudruňka napsal(a):
>>
>> Thx for you answers :-)
>> Well... i know that i can write my own plugin and i am familiar with C so
>> this is not the problem, but i think that such feature should be
>> implemented directly in
On Tue, Dec 21, 2010 at 11:14:31PM +0200, Peter Eisentraut wrote:
> On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
> > On 2010-11-12 8:25 PM +0200, I wrote:
> > > I'm going to take some time off this weekend to get a patch with this
> > > behaviour to the next commitfest.
> >
> > .. and
Hi,
Found a couple of small typos in the comments of nodeWindowAgg.c when
they refer to functions in nodeAgg.c. The pluralities of the function
names (initialize_aggregates and advance_aggregates) are wrong. The
reference to "finalize_aggregate" is correct though.
diff --git a/src/backend/execut
On sön, 2010-11-14 at 04:45 +0200, Marko Tiikkaja wrote:
> On 2010-11-12 8:25 PM +0200, I wrote:
> > I'm going to take some time off this weekend to get a patch with this
> > behaviour to the next commitfest.
>
> .. and a wild patch appears.
>
> This is almost exactly the patch from 2010-02 witho
Hello
Dne 21. prosince 2010 21:11 Tomáš Mudruňka napsal(a):
>
> Thx for you answers :-)
> Well... i know that i can write my own plugin and i am familiar with C so
> this is not the problem, but i think that such feature should be
> implemented directly in PgSQL because there are already function
On Tuesday 21 December 2010 20:25:16 Jesper Krogh wrote:
> What have I missed in the logic?
A reproducible testcase ;-)
Andres
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thx for you answers :-)
Well... i know that i can write my own plugin and i am familiar with C so
this is not the problem, but i think that such feature should be
implemented directly in PgSQL because there are already functions for
converting to/from base 16 so why don't make this more flexible a
Excerpts from Robert Haas's message of mar dic 21 08:40:49 -0300 2010:
> > Well, non-developers don't tend to attach gdb very often. Alvaro
> > mentioned a problem installation upthread, thus the question.
>
> Hearing no cries of "please-oh-please-backpatch-this", I've committed
> it just to mas
On 21.12.2010 21:25, Jesper Krogh wrote:
The first query should have the cost of the GIN-search +
visibillity-test of 158K tuples,
the latter should have the cost of visibillity-testing 168K tuples. If
we set the cost
of actually searching GIN to 0 then the gin-search - visibillity costs:
95/1580
On Tue, Dec 21, 2010 at 2:33 PM, Robert Haas wrote:
> The point of the patch was to improve cases where attaching gdb
> *didn't* work well. Any cases where it was already working for you
> aren't going to be made worse by this.
Okay, great. Thanks for the clarification.
eric
--
Sent via pgsq
On Tue, Dec 21, 2010 at 1:45 PM, Eric Ridge wrote:
> On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
> wrote:
>> On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote:
>>> The attached patch appears to work correctly on MacOS X. I did check,
>>> BTW: getppid() in the attached proce
On Wed, 2010-12-15 at 22:25 +0900, Shigeru HANADA wrote:
> Attached are revised version of SQL/MED core functionality patches.
Looks very interesting new feature, well done.
Can I ask some questions about how this will work?
No particular order, just numbered for reference.
1. The docs don't ac
Hi Hackers.
I have a feeling that GIN is "cheating" on the visibillity checks:
test=# set enable_seqscan = off;
SET
Time: 0.129 ms
test=# select count(id) from fts_test where fts @@ to_tsquery('core');
count
158827
(1 row)
Time: 95.530 ms
test=# explain select count(id) from fts_test
On Mon, Dec 20, 2010 at 3:36 PM, Martijn van Oosterhout
wrote:
> On Mon, Dec 20, 2010 at 03:08:02PM -0500, Robert Haas wrote:
>> The attached patch appears to work correctly on MacOS X. I did check,
>> BTW: getppid() in the attached process returns gdb's pid. Poor!
>
> This appears to be a BSDis
Dne 21.12.2010 16:54, Florian Pflug napsal(a):
>> Hmmm, maybe we could give this possibility (to identify two separate
>> groups of columns) to the user. So instead of 'buid stats for (A,B,C)' the
>> user would say 'build stats for (A,B) and (C)' - this actually represents
>> apriori knowledge of d
amit sehas wrote:
> for the histograms for cost based optimization, is there a rule of
> thumb on how often to rebuild them?
In recent major versions, autovacuum should normally keep you in
good shape. The exception is when you make major changes to the
contents of a table (such as in a bulk
HI,
for the histograms for cost based optimization, is there a rule of thumb on how
often to rebuild them? They are obviously not being continuously updated...what
is the state of the art in this area, do all the other databases also end up
with stale statistics every now and then and have to k
> On Dec21, 2010, at 15:51 , t...@fuzzy.cz wrote:
This is the reason why they choose to always combine the values (with
varying weights).
>>>
>>> There are no varying weights involved there. What they do is to express
>>> P(A=x,B=y) once as
>>>
>>> ...
>>>
>>> P(A=x,B=y) ~= P(B=y|A=x)*P(
On 12/21/2010 07:04 AM, gsdfg gdfg wrote:
Would be great if owner can be inherited from parent object (owner
table ==> schema owner ==> database owner).
CREATE statement could add OWNER TO PARENT to cover this feature.
That syntax would violate POLA in the case of inherited tables (OWNER TO
gsdfg gdfg writes:
> Would be great if owner can be inherited from parent object (owner table ==>
> schema owner ==> database owner).
> CREATE statement could add OWNER TO PARENT to cover this feature.
What it would be is a great security hole --- exactly analogous to
allowing Unix "chown" to non
"Erik Rijkers" writes:
>> http://pgsql.tapoueh.org/extensions/doc/html/sql-alterextension.html
[...]
> Two changes to sql-alterextension.sgml:
Fixed and uploaded on the URL above, will be in the next patch revision,
thanks!
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : E
Robert Haas writes:
> On Wed, Dec 15, 2010 at 11:29 AM, Tom Lane wrote:
>>> - Writeable CTEs - I think we need Tom to pick this one up.
>>> - Fix snapshot taking inconsistencies - Ready for committer. Can any
>>> committer pick this up?
>> Will take a look at these two also.
> Tom, what is your
Would be great if owner can be inherited from parent object (owner table ==>
schema owner ==> database owner).
CREATE statement could add OWNER TO PARENT to cover this feature.
Michel
On Wed, Dec 15, 2010 at 11:29 AM, Tom Lane wrote:
>>> - Writeable CTEs - I think we need Tom to pick this one up.
>>> - Fix snapshot taking inconsistencies - Ready for committer. Can any
>>> committer pick this up?
>
> Will take a look at these two also.
Tom, what is your time frame on this? I t
On Dec21, 2010, at 13:25 , t...@fuzzy.cz wrote:
> And there's one additional - IMHO very important - requirement. The whole
> thing should easily extend to more than two columns. This "IF (F(A,B) >
> F(B,A)) THEN ..." probably is not a good solution regarding this.
>
> For example given 3 columns
On Tue, December 21, 2010 09:57, Dimitri Fontaine wrote:
> "Erik Rijkers" writes:
>> I might be mistaken but it looks like a
>> doc/src/sgml/ref/alter_extension.sgml is missing?
>
> Mmm, it seems that git was agreeing with you, so here's it:
>
> git ls-files doc/src/sgml/ref/alter_extension.sgm
On Dec21, 2010, at 15:51 , t...@fuzzy.cz wrote:
>>> This is the reason why they choose to always combine the values (with
>>> varying weights).
>>
>> There are no varying weights involved there. What they do is to express
>> P(A=x,B=y) once as
>>
>> ...
>>
>> P(A=x,B=y) ~= P(B=y|A=x)*P(A=x)/2 +
> On Dec21, 2010, at 11:37 , t...@fuzzy.cz wrote:
>> I doubt there is a way to this decision with just dist(A), dist(B) and
>> dist(A,B) values. Well, we could go with a rule
>>
>> if [dist(A) == dist(A,B)] the [A => B]
>>
>> but that's very fragile. Think about estimates (we're not going to work
On Dec21, 2010, at 11:37 , t...@fuzzy.cz wrote:
> I doubt there is a way to this decision with just dist(A), dist(B) and
> dist(A,B) values. Well, we could go with a rule
>
> if [dist(A) == dist(A,B)] the [A => B]
>
> but that's very fragile. Think about estimates (we're not going to work
> with
On Dec21, 2010, at 12:48 , Robert Haas wrote:
> 2010/12/21 Tomáš Mudruňka :
>> Is there possibility of having internal base converting function in PgSQL?
>> There are already functions for converting between decimal and hexadecimal
>> notations i think pgsql can be able to convert between number wi
MY PREV EMAIL HAD A PROBLEM. Please reply to this one
==
There is a bug in ts_rank_cd. It does not correctly give rank when the
query lexeme is the first one in the tsvector.
Example:
select ts_rank_cd(to_tsvector('english', 'abc sdd'),
plainto
There is a bug in ts_rank_cd. It does not correctly give rank when the
query lexeme is the first one in the tsvector.
Example:
select ts_rank_cd(to_tsvector('english', 'abc sdd'),
plainto_tsquery('english', 'abc'));
ts_rank_cd
0
select ts_rank_cd(to_tsvector('english'
On Mon, Dec 20, 2010 at 6:42 AM, Itagaki Takahiro
wrote:
> On Sun, Dec 19, 2010 at 12:45, Robert Haas wrote:
>> I'm not questioning any of that. But I'd like the resulting code to
>> be as maintainable as we can make it.
>
> I added comments and moved some setup codes for COPY TO to BeginCopyTo(
On Tue, Dec 21, 2010 at 20:14, Shigeru HANADA wrote:
> Attached is the revised version of file_fdw patch. This patch is
> based on Itagaki-san's copy_export-20101220.diff patch.
#1. Don't you have per-tuple memory leak? I added GetCopyExecutorState()
because the caller needs to reset the per-tup
> On Mon, Dec 20, 2010 at 9:29 PM, Florian Pflug wrote:
>> You might use that to decide if either A->B or B->a looks function-like
>> enough to use the uniform bayesian approach. Or you might even go
>> further,
>> and decide *with* bayesian formula to use - the paper you cited always
>> averages
Dne 21. prosince 2010 12:48 Robert Haas napsal(a):
> 2010/12/21 Tomáš Mudruňka :
>> Is there possibility of having internal base converting function in PgSQL?
>> There are already functions for converting between decimal and hexadecimal
>> notations i think pgsql can be able to convert between num
On Sun, Dec 19, 2010 at 1:10 PM, Jim Nasby wrote:
> On Dec 19, 2010, at 1:10 AM, flyusa2010 fly wrote:
>> Does postgres make an effort to create a file with physically continuous
>> blocks?
>
> AFAIK all files are expanded as needed. I don't think there's any flags you
> can pass to the filesyst
2010/12/21 Tomáš Mudruňka :
> Is there possibility of having internal base converting function in PgSQL?
> There are already functions for converting between decimal and hexadecimal
> notations i think pgsql can be able to convert between number with radixes
> from 1 to 36 (actually fast (de)encodi
On Mon, Dec 20, 2010 at 3:14 PM, Robert Haas wrote:
> On Mon, Dec 20, 2010 at 3:11 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Mon, Dec 20, 2010 at 2:23 PM, Tom Lane wrote:
I like that better actually ... one less thing for developers to get wrong.
>>
>>> The attached patch appears t
On Mon, Dec 20, 2010 at 9:29 PM, Florian Pflug wrote:
> I tried to pick up Robert's idea of quantifying "Implicativeness" -
> i.e., finding a number between 0 and 1 that describes how close the
> (A,B) are to representing a function A -> B.
Actually Heikki's idea...
> Observe that dist(A),dist(B
;
ERROR: missing data for column "bid"
CONTEXT: COPY csv_tellers_bad, line 10: "10"
postgres=#
* Only superusers can change table-level file_fdw options. Normal
user can't change the options even if the user was the owner of the
table. This is for security re
> On Dec18, 2010, at 17:59 , Tomas Vondra wrote:
>> It seems to me you're missing one very important thing - this was not
>> meant as a new default way to do estimates. It was meant as an option
>> when the user (DBA, developer, ...) realizes the current solution gives
>> really bad estimates (due
Alvaro Herrera writes:
> function linkend="functions-extension">pg_extension_flag_dump
[...]
> So presumably this shouldn't be documented because it cannot be called
> anyway?
It can be called but only from an extension's script.
> To be honest I don't understand the purpose of this part o
"Erik Rijkers" writes:
> I might be mistaken but it looks like a doc/src/sgml/ref/alter_extension.sgml
> is missing?
Mmm, it seems that git was agreeing with you, so here's it:
git ls-files doc/src/sgml/ref/alter_extension.sgml
http://git.postgresql.org/gitweb?p=postgresql-extension.git;a
80 matches
Mail list logo
