On Thu, Dec 1, 2011 at 01:06, Andrew Dunstan wrote:
>
>
> On 11/29/2011 04:32 PM, Brar Piening wrote:
>>
>> Andrew Dunstan wrote:
>>>
>>> Some minor nitpicks:
>>>
>>> Do we really need to create all those VSProject.pm and
>>> VSSolution.pm files? They are all always included anyway. Why no
On 30.11.2011 20:45, Tom Lane wrote:
Robert Haas writes:
Yikes! A table with 4 bytes of useful data is consuming 40kB on disk
- 8kB in the main form, 8kB in the VM fork, and 24kB in the FSM fork.
Ouch!
Yeah, ouch. Why is the FSM fork eating so much space --- I'd have
expected 8k there, but
On 11/30/2011 10:20 AM, Greg Stark wrote:
Given your confusion it's clear that we have to explain that it will
wait one by one for each transaction that was started before the index
was created to finish.
When the index was created is a fuzzy thing though. It looked to me
like it makes this c
Jesper Krogh writes:
> I have currently hit a problem which I dug into finding the cause for, in
> particular, searching in GIN indices seems in some situations to
> un-fairly favor Sequential Scans.
> Googling a bit I found this page:
> http://postgis.refractions.net/docs/ch06.html#id2635817
> D
On Wed, 30 Nov 2011, Joel Jacobson wrote:
> As you know, LISTEN/NOTIFY is broken in the Java client library. You have to
> do a SELECT 1 in a while-loop to receive the notifications.
>
> http://jdbc.postgresql.org/documentation/head/listennotify.html
This documentation is out of date. Current
On 11/29/2011 04:32 PM, Brar Piening wrote:
Andrew Dunstan wrote:
Some minor nitpicks:
Do we really need to create all those VSProject.pm and
VSSolution.pm files? They are all always included anyway. Why not
just stash all the packages in Solution.pm and Project.pm?
We certainly
"Kevin Grittner" wrote:
> OK. There are a few things I found in this pass which missed in the
> last. One contrib module was missed, I found another typo in a
> comment, and I think we can reduce the include files a bit. Rather
> than describe it, I'm attaching a patch file over the top of yo
Robert Haas wrote:
> Kevin Grittner wrote:
>> Why is it OK to drop these lines from the else condition in
>> ProcArrayEndTransaction()?:
>>
>>/* must be cleared with xid/xmin: */
>>proc->vacuumFlags &= ~PROC_VACUUM_STATE_MASK;
>
> It's probably not. Oops.
OK. I see that's bac
On Wed, Nov 30, 2011 at 3:58 PM, Stephen Frost wrote:
> Erm, isn't there a contrib type that already does all that for you..?
> ip4r or whatever? Just saying, if you're looking for that capability..
Oh, huh, good to know. Still, I'm not sure why you need to load a
separate type to get this... t
* Robert Haas (robertmh...@gmail.com) wrote:
> A CIDR address defines a range all by itself, without packing any
> other type on top. It just needs GIST support, and an indexable
> operator for "contains or is contained by"; then, you can define an
> exclusion constraint over a CIDR column to enfo
2011/9/13 PostgreSQL - Hans-Jürgen Schönig :
> hello everybody,
>
> here is the next version of the cross column patch.
> in the meantime zoli and i managed to make the cross column sampling work.
> some prototype syntax is already working and we are able to store cross
> column data.
> next on th
On Sun, Nov 27, 2011 at 3:14 PM, Kohei KaiGai wrote:
> If we add new properties that required by AlterObjectNamespace, as
> you suggested, it will allow to reduce number of caller of this routine
> mechanically with small changes.
> Should I try this reworking with this way?
Yeah, let's try that
On Mon, Oct 24, 2011 at 8:40 AM, Fujii Masao wrote:
> On Fri, Oct 21, 2011 at 12:01 PM, Robert Haas wrote:
>> On Thu, Oct 20, 2011 at 9:51 PM, Fujii Masao wrote:
>>> On Thu, Oct 20, 2011 at 1:05 AM, Robert Haas wrote:
OK, so this is an artifact of the changes to make libpq communication
>>
On Mon, Nov 21, 2011 at 11:49 AM, Alexander Korotkov
wrote:
> I've a question about pg_mb2wchar function. Is there any way for inverse
> convertion pg_wchar* to char*?
> I've looked to pg_wchar_tbl table definition, and I didn't find anything
> about inverse transformation. So, any change to get i
On Tue, Nov 22, 2011 at 2:38 PM, Alexander Korotkov
wrote:
> WIP patch with index support for regexp search for pg_trgm contrib is
> attached.
> In spite of techniques which extracts continuous text parts from regexp,
> this patch presents technique of automatum transformation. That allows more
>
Hi list.
I have currently hit a problem which I dug into finding the cause for, in
particular, searching in GIN indices seems in some situations to
un-fairly favor Sequential Scans.
Googling a bit I found this page:
http://postgis.refractions.net/docs/ch06.html#id2635817
Describing the excact p
On 30 nov 2011, at 13:27, Jan Urbański wrote:
> On 30/11/11 13:07, Joel Jacobson wrote:
>> Hi,
>>
>> As you know, LISTEN/NOTIFY is broken in the Java client library. You have
>> to do a SELECT 1 in a while-loop to receive the notifications.
>>
>> http://jdbc.postgresql.org/documentation/head/li
Tom Lane wrote:
> For the moment I duplicated the existing logic of overriding
> relevant GUC variables in the process's Main() function,
Thanks!
> but I wonder if we ought to be setting these things in some more
> centralized place, like InitPostgres(). That function already
> knows quite
Robert Haas writes:
> Yikes! A table with 4 bytes of useful data is consuming 40kB on disk
> - 8kB in the main form, 8kB in the VM fork, and 24kB in the FSM fork.
> Ouch!
Yeah, ouch. Why is the FSM fork eating so much space --- I'd have
expected 8k there, but 24?
Also, if VACUUM is going to ca
Joe Abbate wrote:
> On 11/30/2011 11:26 AM, Kevin Grittner wrote:
>> You are prepared to handle the difference between char and
>> "char", I hope.
> Pyrseas depends on the ultimate type verifier: the
> PostgreSQL parser (and related routines).
OK. I just wanted to be sure that you were aware
On Wed, Nov 30, 2011 at 12:29 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, Nov 27, 2011 at 10:24 AM, Florian Weimer wrote:
>>> I noticed that a bulk INSERT into an empty table (which has been
>>> TRUNCATEd in the same transaction, for good measure) results in a
>>> curious number of open
Pavel Stehule writes:
> I rechecked a possibility to use a validator function together with
> checker function.
> The main issue is a different interface of both functions. Validator
> needs just function oid and uses global variable
> check_function_bodies. Checker function needs function oid an
On Wed, Nov 30, 2011 at 1:08 PM, Jeff Davis wrote:
> One that I'd like to see is an IP address type, but that's complicated
> because inet and cidr support netmasks.
A CIDR address defines a range all by itself, without packing any
other type on top. It just needs GIST support, and an indexable
Hello
I rechecked a possibility to use a validator function together with
checker function.
The main issue is a different interface of both functions. Validator
needs just function oid and uses global variable
check_function_bodies. Checker function needs function oid and
relation oid (possible s
On Wed, Nov 30, 2011 at 8:02 AM, Greg Smith wrote:
Except in the sections talking about locking
internals we don't talk about "shared locks on virtual transactions
identifiers" we just talk about waiting for a transaction to complete.
> What I cannot agree with is that idea that th
Jeff Davis writes:
> On Tue, 2011-11-29 at 12:01 -0500, Tom Lane wrote:
>> In particular, I don't understand why there's not a
>> standard float8range type; that seems like a pretty common case.
>> I'd have also expected to see a standard textrange type. What was
>> the rationale for leaving thes
On Tue, 2011-11-29 at 12:01 -0500, Tom Lane wrote:
> One thing that bothered me while looking at the range types patch is
> that it seemed you'd been mighty conservative about creating built-in
> range types.
During development, I didn't want to juggle the OIDs for too many range
types. That was r
On 11/30/2011 11:26 AM, Kevin Grittner wrote:
> You are prepared to handle the difference between char and "char", I
> hope.
We have not implemented a type "verifier" in Pyrseas. It currently
generates SQL based on the type given in the input. In normal usage,
dbtoyaml is expected to be invoked
Robert Haas writes:
> On Sun, Nov 27, 2011 at 10:24 AM, Florian Weimer wrote:
>> I noticed that a bulk INSERT into an empty table (which has been
>> TRUNCATEd in the same transaction, for good measure) results in a
>> curious number of open(2) calls for the FSM resource fork:
> That's kind of un
On Sun, Nov 27, 2011 at 10:24 AM, Florian Weimer wrote:
> I noticed that a bulk INSERT into an empty table (which has been
> TRUNCATEd in the same transaction, for good measure) results in a
> curious number of open(2) calls for the FSM resource fork:
That's kind of unfortunate. It looks like ev
Pavel Stehule writes:
> 2011/11/30 Tom Lane :
>> It seems pretty awkward to me, particularly putting the options before
>> the second keyword of the command --- that could bite us if we ever want
>> some other flavors of CHECK command. I prefer Robert's suggestion of a
>> WITH clause at the end.
On Mon, Nov 28, 2011 at 9:18 AM, Mikko Tiihonen
wrote:
> Hi,
>
> As discussed few days ago it would be beneficial if we could change the v3
> backend<->client protocol without breaking backwards compatibility.
>
> Here is a working patch that exports a supported_binary_minor constant and a
> binar
2011/11/30 Tom Lane :
> Pavel Stehule writes:
>> 2011/11/30 Alvaro Herrera :
>>> How about
>>> CHECK (parse, names=off) FUNCTION foobar(a, b, c)
>
>> this syntax is relative consistent with EXPLAIN, is it ok for all?
>
> It seems pretty awkward to me, particularly putting the options before
> the
Joe Abbate wrote:
> On 11/30/2011 09:55 AM, Tom Lane wrote:
>> One possible solution, if you're getting type information about
>> columns from the server, is to cast the type OID to regtype and
>> let the regtype output converter make all the decisions. It's
>> less notation than a join to pg_typ
On 11/30/2011 09:55 AM, Tom Lane wrote:
> One possible solution, if you're getting type information about columns
> from the server, is to cast the type OID to regtype and let the regtype
> output converter make all the decisions. It's less notation than a join
> to pg_type anyway.
Unfortunately,
Pavel Stehule writes:
> 2011/11/30 Alvaro Herrera :
>> How about
>> CHECK (parse, names=off) FUNCTION foobar(a, b, c)
> this syntax is relative consistent with EXPLAIN, is it ok for all?
It seems pretty awkward to me, particularly putting the options before
the second keyword of the command ---
On Mon, Nov 28, 2011 at 10:18 AM, Mikko Tiihonen
wrote:
> Here is a working patch that exports a supported_binary_minor constant and a
> binary_minor session variable and a that can be used by clients to enable
> newer features.
Can you add this patch here so we don't lose track of it?
https://c
2011/11/30 Alvaro Herrera :
>
> Excerpts from Tom Lane's message of mié nov 30 12:53:42 -0300 2011:
>
>> A bigger issue is that once you think about more than one kind of check,
>> it becomes apparent that we might need some user-specifiable options to
>> control which checks are applied. And I se
Robert Haas writes:
> On Wed, Nov 30, 2011 at 10:53 AM, Tom Lane wrote:
>> On the whole, it might not be a bad idea to have two allowed signatures
>> for the validator function, rather than inventing an additional column
>> in pg_language. But the fundamental point IMHO is that there needs to
>>
On 11/29/2011 10:01 AM, Andrew Dunstan wrote:
I don't have a VS2010 machine available to test it on unfortunately.
I'll see what I can do about arranging one, at least temporarily.
Meanwhile I'll test it on my VS2005 and VS2008 machines to make sure
it doesn't break anything.
I can conf
Excerpts from Tom Lane's message of mié nov 30 12:53:42 -0300 2011:
> A bigger issue is that once you think about more than one kind of check,
> it becomes apparent that we might need some user-specifiable options to
> control which checks are applied. And I see no provision for that here.
> Thi
On Wed, Nov 30, 2011 at 10:53 AM, Tom Lane wrote:
> On the whole, it might not be a bad idea to have two allowed signatures
> for the validator function, rather than inventing an additional column
> in pg_language. But the fundamental point IMHO is that there needs to
> be a provision to pass lan
Hello
>
> CREATE OR REPLACE FUNCTION t(i integer) RETURNS integer
> LANGUAGE plpgsql STRICT AS
> $$DECLARE j integer;
> BEGIN
> IF i=1 THEN
> FOR I IN 1..4 BY -1 LOOP
> RAISE NOTICE '%', i;
> END LOOP;
> RETURN -1;
> ELSE
> RETURN 2*i;
> EN
"Albe Laurenz" writes:
> Do I understand right that the reason why the check function is
> different from the validator function is that it would be more difficult
> to add the checks to the validator function?
> Is that a good enough argument? From a user's perspective it is
> difficult to see w
Hello
2011/11/28 Greg Smith :
> I'm trying to find someone for the "[PL/pgSQL] %TYPE and array declaration -
> second patch" patch submitted recently:
> https://commitfest.postgresql.org/action/patch_view?id=666
>
> Not too many people work on the PL/pgSQL code, and I see you reviewed an
> earlie
Pavel Stehule wrote:
> updated patch:
>
> * recheck compilation and initdb
> * working routines moved to pl_exec.c
> * add entry to catalog.sgml about lanchecker field
> * add node's utils
Documentation:
--
This patch has no documentation for CHECK FUNCTION or CHECK TRIGGER.
The last
Andrew Dunstan writes:
> On 11/30/2011 09:02 AM, Alvaro Herrera wrote:
>> I wonder if it would simpler to just not quote type names except when
>> absolutely necessary.
> Yeah, and very much less ugly. Ploughing through masses of unnecessary
> quotes is they way to a headache. quote_ident() gets
On 11/30/2011 09:02 AM, Alvaro Herrera wrote:
Excerpts from Joe Abbate's message of mié nov 30 02:15:09 -0300 2011:
Thanks Tom and Robert. I think I understand the problem now. I guess
I'll have to work around this "quirk" by dealing specially with type
names and not quote them when they're
Excerpts from Joe Abbate's message of mié nov 30 02:15:09 -0300 2011:
> Thanks Tom and Robert. I think I understand the problem now. I guess
> I'll have to work around this "quirk" by dealing specially with type
> names and not quote them when they're in the shorter list of SQL
> Standard reser
On 11/30/2011 07:27 AM, Jan Urbański wrote:
On 30/11/11 13:07, Joel Jacobson wrote:
Hi,
As you know, LISTEN/NOTIFY is broken in the Java client library. You
have
to do a SELECT 1 in a while-loop to receive the notifications.
http://jdbc.postgresql.org/documentation/head/listennotify.html
On Wed, Nov 30, 2011 at 3:02 AM, Greg Smith wrote:
> I will happily accept that the description there may have suffered from me
> not using all of the terms optimally, and that the resulting commit could be
> improved. Some more feedback to get the description correct and useful
> would be much a
On Wed, Nov 30, 2011 at 1:37 AM, YAMAMOTO Takashi
wrote:
>> Yes, I would expect that. What kind of increase are you seeing? Is
>> it causing a problem for you, or are you just making an observation?
>
> i was curious because my application uses async commits mainly to
> avoid frequent fsync. i
On 30/11/11 13:07, Joel Jacobson wrote:
Hi,
As you know, LISTEN/NOTIFY is broken in the Java client library. You have
to do a SELECT 1 in a while-loop to receive the notifications.
http://jdbc.postgresql.org/documentation/head/listennotify.html
Is there some other library with a proper impleme
Hi,
As you know, LISTEN/NOTIFY is broken in the Java client library. You have
to do a SELECT 1 in a while-loop to receive the notifications.
http://jdbc.postgresql.org/documentation/head/listennotify.html
Is there some other library with a proper implementation where you don't
have to spam the d
Hi
I have a "feeling" that the internal query-plans (or alternative)
query-plans when executing GIN-searches are not being exhausted as much as
they generally are in PG.
More specifically a query like:
select id from table where fts @@ to_tsquery('english','verycommon &
veryrare');
Can do an s
hi,
> On Tue, Nov 29, 2011 at 1:42 AM, YAMAMOTO Takashi
> wrote:
>>> On Mon, Nov 7, 2011 at 5:26 PM, Simon Riggs wrote:
>>>
> 5. Make the WAL writer more responsive, maybe using latches, so that
> it doesn't take as long for the commit record to make it out to disk.
I'm working
Excerpts from Greg Stark's message of sáb jun 25 21:01:36 -0400 2011:
I think this commit was ill-advised:
http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=a03feb9354bda5084f19cc952bc52ba7be89f372
Seems way to implementation-specific and detailed for a user to make
heads or tails
57 matches
Mail list logo
