On Aug 6, 2010, at 10:49 PM, Pavel Stehule wrote:
>> Huh? You can select into an array:
>
> and pg doesn't handle 2D arrays well - can't to use ARRAY(subselect)
> constructor for 2D arrays
Right.
>> try=# select ARRAY(SELECT ARRAY[k,v] FROM foo);
>> ERROR: could not find array type for datatyp
2010/8/7 David E. Wheeler :
> On Aug 6, 2010, at 10:15 PM, Pavel Stehule wrote:
>
>>> This is not exactly without precedent, either: our built-in xpath()
>>> function appears to use precisely this approach for its namespace-list
>>> argument.
>>
>> it's one variant, but isn't perfect
>>
>> a) it ex
2010/8/7 David E. Wheeler :
> On Aug 6, 2010, at 9:48 PM, Pavel Stehule wrote:
>
>>> That's exactly what my solution does. The array solution doesn't. Whether
>>> it's appropriate to use a custom composite type, however, is an open
>>> question.
>>
>> no it doesn't - in your design there are no d
On Aug 6, 2010, at 10:15 PM, Pavel Stehule wrote:
>> This is not exactly without precedent, either: our built-in xpath()
>> function appears to use precisely this approach for its namespace-list
>> argument.
>
> it's one variant, but isn't perfect
>
> a) it expects so key and value are literals
On Aug 6, 2010, at 9:59 PM, Tom Lane wrote:
> It's not immediately clear to me what an ordered-pair type would get you
> that you don't get with 2-element arrays.
Just syntactic sugar, really. And control over how many items you have (a
bounded pair rather than an unlimited element array).
> A
2010/8/7 Tom Lane :
> "David E. Wheeler" writes:
>> I think that some sort of variadic pairs would be useful for this. But since
>> there is no core "ordered pair" data type, I don't think you're going to get
>> too far.
>
> It's not immediately clear to me what an ordered-pair type would get yo
On Aug 6, 2010, at 9:48 PM, Pavel Stehule wrote:
>> That's exactly what my solution does. The array solution doesn't. Whether
>> it's appropriate to use a custom composite type, however, is an open
>> question.
>
> no it doesn't - in your design there are no different notation for key
> and for
"David E. Wheeler" writes:
> I think that some sort of variadic pairs would be useful for this. But since
> there is no core "ordered pair" data type, I don't think you're going to get
> too far.
It's not immediately clear to me what an ordered-pair type would get you
that you don't get with 2-
2010/8/7 David E. Wheeler :
> On Aug 6, 2010, at 8:49 PM, Pavel Stehule wrote:
>
>>> Sorry, not following you here
>>
>> I would to difference a key and value in notation.
>
> That's exactly what my solution does. The array solution doesn't. Whether
> it's appropriate to use a custom composite typ
Robert Haas wrote:
>
> My thought would be "is autovacuum running in the background in
> between these commands?".
>
That's a good thought, but no, autovacuum_vacuum_scale_factor is set to 0.2,
meaning that over 1 million dead tuples are necessary for autovacuum.
Besides, if autovacuum had ru
On Aug 6, 2010, at 8:49 PM, Pavel Stehule wrote:
>> Sorry, not following you here
>
> I would to difference a key and value in notation.
That's exactly what my solution does. The array solution doesn't. Whether it's
appropriate to use a custom composite type, however, is an open question.
>> P
2010/8/7 Joshua Tolley :
> On Thu, Aug 05, 2010 at 04:46:51PM +0200, Pavel Stehule wrote:
>> I am sending a updated version.
>
> I've been looking at the changes to gram.y, and noted the comment under
> func_expr
> where you added CUBE and ROLLUP definitions. It says that CUBE can't be a
> reserve
2010/8/7 Tom Lane :
> "David E. Wheeler" writes:
>> On Aug 6, 2010, at 2:12 PM, Pavel Stehule wrote:
>>> so there is only small step to proposed feature
>>> SELECT foo(this := 'that', "1" := 4)
>
>> Sorry, not following you here
I would to difference a key and value in notation.
>
> Pavel doesn'
(2010/08/07 0:02), Robert Haas wrote:
At PGCon, we discussed the possibility that a minimal SE-PostgreSQL
implementation would need little more than a hook in
ExecCheckRTPerms() [which we've since added] and a security label
facility [for which KaiGai has submitted a patch]. I actually sat
down
Peter Eisentraut writes:
> Next version. Changed dependencies to pg_constraint, removed handling
> of unique constraints for now, and made some enhancements so that views
> track dependencies on constraints even in subqueries. Should be close
> to final now. :-)
I've committed this with some re
On Fri, Aug 6, 2010 at 9:11 PM, Itagaki Takahiro
wrote:
> 2010/8/7 Gordon Shannon :
>> 1. I delete 10,000 rows.
>> pgstattuple.dead_tuple_count -> 1
>>
>> 2. I delete 15,000 more rows.
>> pgstattuple.dead_tuple_count -> 15000 ??
>>
>> pgstattuple now appears to count the earlier 10K deleted tu
2010/8/7 Gordon Shannon :
> 1. I delete 10,000 rows.
> pgstattuple.dead_tuple_count -> 1
>
> 2. I delete 15,000 more rows.
> pgstattuple.dead_tuple_count -> 15000 ??
>
> pgstattuple now appears to count the earlier 10K deleted tuples as no longer
> dead, but free space.
I think it's expected b
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
>
I think there's a snag in the patch:
postgres=# COPY data FROM '/Users/jwp/DATA.bcopy' WITH BINARY;
ERROR: row field count is -1, expected 1
CONTEXT: COPY data, line 4
Probably a quick/small fix away, I imagine.
But, I was able to trigger the
2010/7/26 Robert Haas :
> Come to think of it, have we checked that the behavior of LEFT, RIGHT,
> REVERSE, etc. is the same on other DBs, especially as far as nulls,
> empty strings, too-large or negative subscripts, etc is concerned? Is
> CONCAT('foo', NULL) => 'foo' really the behavior that eve
On Wed, 28 Jul 2010, James William Pye wrote:
Not directly regarding your patch, but while the discussion is in the
general area. I think it would be wise to throw an error when non-empty
CopyData messages are received after CopyData(EOF). Chances are that the
user is making a mistake and sh
On Fri, Aug 6, 2010 at 6:49 PM, David E. Wheeler
wrote:
> On Aug 6, 2010, at 3:38 PM, Tom Lane wrote:
>
>>> We definitely need to document the `text % text` constructor
>>
>> BTW, there isn't any % constructor anymore --- we agreed to provide
>> only the hstore(text, text) constructor.
>
> Oh, I m
On Aug 6, 2010, at 3:38 PM, Tom Lane wrote:
>> We definitely need to document the `text % text` constructor
>
> BTW, there isn't any % constructor anymore --- we agreed to provide
> only the hstore(text, text) constructor.
Oh, I must've been looking at an older checkout, then. Never mind.
Best,
On Fri, Aug 06, 2010 at 11:48:58PM +0300, Peter Eisentraut wrote:
> On fre, 2010-08-06 at 21:31 +0200, Pavel Stehule wrote:
> > It must not be a function. Just I missing any tool that helps with
> > complex structured data. This proposed kind functions has one
> > advantage - there isn't necessary
"David E. Wheeler" writes:
> We definitely need to document the `text % text` constructor
BTW, there isn't any % constructor anymore --- we agreed to provide
only the hstore(text, text) constructor.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers
"David E. Wheeler" writes:
> On Aug 6, 2010, at 3:16 PM, Tom Lane wrote:
>> It looks to me like you are changing the examples of the I/O
>> representation ... which did NOT change.
> Hrm? The first few examples at the top? I find them confusing because there
> are no single quotes around them, s
On Thu, Aug 05, 2010 at 04:46:51PM +0200, Pavel Stehule wrote:
> I am sending a updated version.
I've been looking at the changes to gram.y, and noted the comment under
func_expr
where you added CUBE and ROLLUP definitions. It says that CUBE can't be a
reserved keyword because it's already used i
On Aug 6, 2010, at 3:16 PM, Tom Lane wrote:
>> I noticed that the hstore docs still document the => operator instead
>> of %. This patch changes that.
>
> It looks to me like you are changing the examples of the I/O
> representation ... which did NOT change.
Hrm? The first few examples at the to
"David E. Wheeler" writes:
> I noticed that the hstore docs still document the => operator instead
> of %. This patch changes that.
It looks to me like you are changing the examples of the I/O
representation ... which did NOT change.
regards, tom lane
--
Sent via pgsql-
"David E. Wheeler" writes:
> On Aug 6, 2010, at 2:12 PM, Pavel Stehule wrote:
>> so there is only small step to proposed feature
>> SELECT foo(this := 'that', "1" := 4)
> Sorry, not following you here
Pavel doesn't understand "no" ;-)
regards, tom lane
--
Sent via pgsq
Peter Eisentraut writes:
> On fre, 2010-08-06 at 13:01 -0400, Tom Lane wrote:
>> 2. I'm not sure whether we ought to auto-single-quote the values.
>> If we don't, how hard is it for users to properly quote nonconstant
>> parameter values? (Will quote_literal work, or are the quoting rules
>> diff
On Fri, Aug 6, 2010 at 4:52 PM, Peter Eisentraut wrote:
> On fre, 2010-08-06 at 07:31 -0400, Robert Haas wrote:
>> > What about making the function sensitive to the XML OPTION, such
>> that:
>> >
>> > test=# SET xmloption TO DOCUMENT;
>> > SET
>> > text=# SELECT xml_is_well_formed('foo');
>> >
>>
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> [ review of gincostestimate-0.19 ]
I went through this patch, re-synced with current HEAD, and did some
minor editorializing; a new version is attached. (Caution: I have not
tested this beyond verifying that it still compiles.)
> Codewise I have one qu
On Aug 6, 2010, at 2:12 PM, Pavel Stehule wrote:
>> SELECT foo('this' ~> 'that', 1 ~> 4);
>>
>> Not bad, I think. I kind of like it. It reminds me how much I hate the %
>> hstore construction operator, though (the new name for =>).
>
> so there is only small step to proposed feature
>
> SELECT
On tor, 2010-08-05 at 16:35 +0100, Simon Riggs wrote:
> * DELETE is an extension to the standard, though supported by Oracle,
> DB2 and SQLServer and damn useful
-> SQL:2011
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.po
2010/8/6 David E. Wheeler :
> On Aug 6, 2010, at 1:49 PM, Pavel Stehule wrote:
>
>> yes it is one a possibility and probably best. The nice of this
>> variant can be two forms like current variadic does - foo(.., a :=
>> 10, b := 10) or foo(.., variadic ARRAY[(a,10),(b,10)])
>
> I started fiddling
Hackers,
I noticed that the hstore docs still document the => operator instead of %.
This patch changes that. It also updates the first examples to us full SQL
statements, because otherwise the use of => without surrounding single quotes
was confusing.
Best,
David
hstoredoc.patch
Descripti
On ons, 2010-08-04 at 19:32 +0200, Jan Otto wrote:
> patch against HEAD is attached and validated against a lot of
> previously wrong and correct hyphenated isbn.
I think this module could use a regression test.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make chang
On mån, 2010-07-26 at 10:46 -0600, Alex Hunsaker wrote:
> On Sat, Jul 24, 2010 at 06:23, Peter Eisentraut wrote:
>
> > Another open question I thought of was whether we should put the
> > dependency record on the pg_index row, or the pg_constraint row, or
> > perhaps the pg_class row. Right now,
On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule wrote:
> I'll propose a new kind of functions (only position parameter's
> function). My idea is simple - for functions with this mark the mixed
> and named notation is blocked. But these functions can have a
> parameter names - and these names can be
On Aug 6, 2010, at 1:49 PM, Pavel Stehule wrote:
> yes it is one a possibility and probably best. The nice of this
> variant can be two forms like current variadic does - foo(.., a :=
> 10, b := 10) or foo(.., variadic ARRAY[(a,10),(b,10)])
I started fiddling and got as far as this:
CREATE TYP
On fre, 2010-08-06 at 14:43 +0100, Mike Fowler wrote:
> > Or perhaps it could return a string instead of a boolean: content,
> > document, or NULL if it's neither.
> >
>
> I like the sound of that. In fact this helps workaround the IS
> DOCUMENT
> and IS CONTENT limitations such that you can
On fre, 2010-08-06 at 07:31 -0400, Robert Haas wrote:
> > What about making the function sensitive to the XML OPTION, such
> that:
> >
> > test=# SET xmloption TO DOCUMENT;
> > SET
> > text=# SELECT xml_is_well_formed('foo');
> >
> > xml_is_well_formed
> >
> > f
> > (1 row)
> yes it is one a possibility and probably best. The nice of this
> variant can be two forms like current variadic does - foo(.., a :=
> 10, b := 10) or foo(.., variadic ARRAY[(a,10),(b,10)])
>
>
pardon foo(..., VARIADIC ARRAY[('a', 10), ('b' 10)])
regards
Pavel
--
Sent via pgsql-hackers maili
2010/8/6 Peter Eisentraut :
> On fre, 2010-08-06 at 21:31 +0200, Pavel Stehule wrote:
>> It must not be a function. Just I missing any tool that helps with
>> complex structured data. This proposed kind functions has one
>> advantage - there isn't necessary any change in parser. Yes, I can use
>> a
2010/8/6 David E. Wheeler :
> On Aug 6, 2010, at 11:13 AM, Tom Lane wrote:
>
>> That would work too, although I think it might be a bit harder to use
>> than one alternating-name-and-value array, at least in some scenarios.
>> You'd have to be careful that you got the values in the same order in
>>
On fre, 2010-08-06 at 21:31 +0200, Pavel Stehule wrote:
> It must not be a function. Just I missing any tool that helps with
> complex structured data. This proposed kind functions has one
> advantage - there isn't necessary any change in parser. Yes, I can use
> a pair of arrays, I can use a one a
On fre, 2010-08-06 at 13:01 -0400, Tom Lane wrote:
> 2. I'm not sure whether we ought to auto-single-quote the values.
> If we don't, how hard is it for users to properly quote nonconstant
> parameter values? (Will quote_literal work, or are the quoting rules
> different for libxslt?) If we do, a
Excerpts from Robert Haas's message of vie ago 06 15:32:21 -0400 2010:
> > Perhaps run through pg_class after restart and flush anything marked
> > relistemp?
>
> The trouble is that you have to bind to a database before you can run
> through pg_class, and the postmaster doesn't. Of course, if i
On Friday 06 August 2010 20:23:15 Tom Lane wrote:
> Andres Freund writes:
> > The most prohibitively expensive part is the AtEOXact_Buffers check of
> > running through all buffers and checking their pin count. And it makes
> > $app's regression tests take thrice their time...
> >
> > Would someb
On Aug 6, 2010, at 11:13 AM, Tom Lane wrote:
> That would work too, although I think it might be a bit harder to use
> than one alternating-name-and-value array, at least in some scenarios.
> You'd have to be careful that you got the values in the same order in
> both arrays, which'd be easy to bo
On fre, 2010-08-06 at 09:04 +0100, Mike Fowler wrote:
> If the patch is to be committed, does it make sense for me to refine
> it such that it uses the new xpath internal function you extracted in
> the xmlexists patch?
Yes, you can probably shrink this patch down to about 20 lines.
--
Sent via
On 06/08/10 17:31, Fujii Masao wrote:
On Fri, Aug 6, 2010 at 10:10 PM, Alanoly Andrews wrote:
I’m testing “hot standby” using “streaming WAL records”. On trying to bring
(dbx) where
_alloc_initial_pthread(??) at 0x949567c
__pth_init(??) at 0x9493ba4
uload(??, ??, ??, ??, ??, ??,
On Fri, Aug 6, 2010 at 2:43 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 6, 2010 at 2:07 PM, Tom Lane wrote:
>>> Sure, it tops out somewhere, but 32K is way too close to configurations
>>> we know work well enough in the field (I've seen multiple reports of
>>> people using a couple
On Fri, Aug 6, 2010 at 3:00 PM, Tom Lane wrote:
> Robert Haas writes:
>> This patch only directly addresses the issue of cleaning up the
>> storage, so there are still the catalog entries to worry about. But
>> it doesn't seem impossible to think about building on this approach to
>> eventually
2010/8/6 Tom Lane :
> Pavel Stehule writes:
>> For Tom: proposed syntax can be used generally - everywhere when you
>> are working with collection. It can be used for hash (hstore)
>> constructor for example. For me is more readable code like
>
>> select hstore(name := 'Tomas', surname := 'Novak')
David Fetter writes:
> On Fri, Aug 06, 2010 at 03:00:35PM -0400, Tom Lane wrote:
>> Perhaps run through pg_class after restart and flush anything marked
>> relistemp? Although the ideal solution, probably, would be for temp
>> tables to not have persistent catalog entries in the first place.
> F
On Fri, Aug 06, 2010 at 03:00:35PM -0400, Tom Lane wrote:
> Robert Haas writes:
> > This patch only directly addresses the issue of cleaning up the
> > storage, so there are still the catalog entries to worry about.
> > But it doesn't seem impossible to think about building on this
> > approach to
Robert Haas writes:
> This patch only directly addresses the issue of cleaning up the
> storage, so there are still the catalog entries to worry about. But
> it doesn't seem impossible to think about building on this approach to
> eventually handle that part of the problem better, too. I haven't
Robert Haas writes:
> On Fri, Aug 6, 2010 at 2:07 PM, Tom Lane wrote:
>> Sure, it tops out somewhere, but 32K is way too close to configurations
>> we know work well enough in the field (I've seen multiple reports of
>> people using a couple thousand backends).
> Well, I wouldn't expect anyone t
On Fri, Aug 6, 2010 at 2:16 PM, Tom Lane wrote:
> Jaime Casanova writes:
>> On Fri, Aug 6, 2010 at 12:50 PM, Robert Haas wrote:
>>> Just "DROP TABLE pg_temp_2.foo" or whatever and away you go.
>
>> wow! that's true... and certainly a bug...
>
> No, it's not a bug. You'll find only superusers ca
Pavel Stehule writes:
> For Tom: proposed syntax can be used generally - everywhere when you
> are working with collection. It can be used for hash (hstore)
> constructor for example. For me is more readable code like
> select hstore(name := 'Tomas', surname := 'Novak')
You've tried to sell us o
This is an expansion of the question I posed in this thread:
http://postgresql.1045698.n5.nabble.com/Need-help-understanding-vacuum-verbose-output-tp2265895p2266912.html
I am framing the question here in relation to pgstattuple. Running 8.4.4 on
Centos.
I have a table T with 5,063,463 rows.
On Fri, Aug 6, 2010 at 2:07 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Fri, Aug 6, 2010 at 1:14 PM, Tom Lane wrote:
>>> Really? Surely that should be illegal during normal operation. We
>>> might be doing such during crash recovery, but we don't need to
>>> broadcast sinval messages then.
Andres Freund writes:
> The most prohibitively expensive part is the AtEOXact_Buffers check of
> running
> through all buffers and checking their pin count. And it makes $app's
> regression tests take thrice their time...
> Would somebody object agains putting those in an extra define so that
Jaime Casanova writes:
> On Fri, Aug 6, 2010 at 12:50 PM, Robert Haas wrote:
>> Just "DROP TABLE pg_temp_2.foo" or whatever and away you go.
> wow! that's true... and certainly a bug...
No, it's not a bug. You'll find only superusers can do it.
> we shouldn't allow any session to drop other s
Robert Haas writes:
> Why wouldn't we just pass two text arrays to this function and be done
> with it?
That would work too, although I think it might be a bit harder to use
than one alternating-name-and-value array, at least in some scenarios.
You'd have to be careful that you got the values in
On Fri, Aug 6, 2010 at 12:50 PM, Robert Haas wrote:
>
> Just "DROP TABLE
> pg_temp_2.foo" or whatever and away you go.
>
wow! that's true... and certainly a bug...
we shouldn't allow any session to drop other session's temp tables, or
is there a reason for this misbehavior?
--
Jaime Casanova
2010/8/6 Robert Haas :
> On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule wrote:
>> I'll propose a new kind of functions (only position parameter's
>> function). My idea is simple - for functions with this mark the mixed
>> and named notation is blocked. But these functions can have a
>> parameter na
Robert Haas writes:
> On Fri, Aug 6, 2010 at 1:14 PM, Tom Lane wrote:
>> Really? Surely that should be illegal during normal operation. We
>> might be doing such during crash recovery, but we don't need to
>> broadcast sinval messages then.
> autovacuum.c does it when we start to worry about XI
Pavel Stehule writes:
> 2010/8/6 Tom Lane :
>> I think there are issues here that we need to take a step back and think
>> about. Â Right now, thanks to the lack of documentation, we can probably
>> assume there are approximately zero users of the xslt_process parameter
>> feature. Â Once we docum
Hi,
I do test (and even run) some stuff running with cassert enabled. For many
things the reliability and performance is ok enough and its useful, especially
if you have your own c functions and such.
Imho thats useful as it makes catching some bugs more likely...
The most prohibitively expensi
On Fri, Aug 6, 2010 at 1:14 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Aug 5, 2010 at 7:05 PM, Tom Lane wrote:
>>> One thing that I find rather distressing about this is the 25% bloat
>>> in sizeof(SharedInvalidationMessage). Couldn't we avoid that? Is it
>>> really necessary to *eve
2010/8/6 Tom Lane :
> Andrew Dunstan writes:
>> On 08/06/2010 12:15 PM, Tom Lane wrote:
>>> Some examination of
>>> http://www.xmlsoft.org/XSLT/tutorial/libxslttutorial.html
>>> suggests that the parameter values need to be single-quoted,
>>> and indeed when I change the last part of your example
Robert Haas writes:
> On Thu, Aug 5, 2010 at 7:05 PM, Tom Lane wrote:
>> One thing that I find rather distressing about this is the 25% bloat
>> in sizeof(SharedInvalidationMessage). Couldn't we avoid that? Is it
>> really necessary to *ever* send an SI message for a backend-local rel?
> It ca
Andrew Dunstan writes:
> On 08/06/2010 12:15 PM, Tom Lane wrote:
>> Some examination of
>> http://www.xmlsoft.org/XSLT/tutorial/libxslttutorial.html
>> suggests that the parameter values need to be single-quoted,
>> and indeed when I change the last part of your example to
>>
>> 'n1=''v1'',n2=''v
On Thu, Aug 5, 2010 at 7:05 PM, Tom Lane wrote:
> Robert Haas writes:
>> [ BackendRelFileNode patch ]
>
> One thing that I find rather distressing about this is the 25% bloat
> in sizeof(SharedInvalidationMessage). Couldn't we avoid that? Is it
> really necessary to *ever* send an SI message fo
On 08/06/2010 12:15 PM, Tom Lane wrote:
Some examination of
http://www.xmlsoft.org/XSLT/tutorial/libxslttutorial.html
suggests that the parameter values need to be single-quoted,
and indeed when I change the last part of your example to
'n1=''v1'',n2=''v2'',n3=''v3'',n4=''v4'',n5=''v5
Hello
attached updated patch with regression test
2010/8/6 Tom Lane :
> Mike Fowler writes:
>> SELECT
>> xslt_process( ... , ... ,
>> 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
>
> produces
>
>>
>> v1
>> v2
>> v3
>> v4
>> v5
>>
>
>> Sadly I get the following in both v
On Fri, Aug 6, 2010 at 12:26 PM, Simon Riggs wrote:
> I understand the concept and it seems like it might work. Not too keen
> on pretending a noun is a verb. That leads to erroring.
>
> SECURITY LABEL? verb = CREATE, ADD, ...
>
> Can't objects have more than one label?
>
> How will you set defau
On Fri, 2010-08-06 at 11:02 -0400, Robert Haas wrote:
> At PGCon, we discussed the possibility that a minimal SE-PostgreSQL
> implementation would need little more than a hook in
> ExecCheckRTPerms() [which we've since added] and a security label
> facility [for which KaiGai has submitted a patch].
Mike Fowler writes:
> SELECT
> xslt_process( ... , ... ,
> 'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
produces
>
>v1
>v2
>v3
>v4
>v5
>
> Sadly I get the following in both versions:
>
>
>
>
>
>
>
Some examination of
http://www.xmlsoft.org/X
On Fri, Aug 6, 2010 at 11:36 AM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of vie ago 06 11:02:58 -0400 2010:
>
>> Any comments? (ha ha ha...)
>
> Interesting idea. The patch looks fine on a quick once-over.
Thanks for taking a look.
> Two small
> things: this comment
>
> +
Excerpts from Robert Haas's message of vie ago 06 11:02:58 -0400 2010:
> Any comments? (ha ha ha...)
Interesting idea. The patch looks fine on a quick once-over. Two small
things: this comment
+/*
+ * Databases, tablespaces, and roles are cluster-wide objects, so any
+ * comments
Thanks. Yes, the LOAD command does work, on another database cluster on the
same AIX machine.
-Original Message-
From: Fujii Masao [mailto:masao.fu...@gmail.com]
Sent: Friday, August 06, 2010 10:31 AM
To: Alanoly Andrews
Cc: pgsql-ad...@postgresql.org; PostgreSQL-development
Subject: Re:
On Aug3, 2010, at 00:43 , Florian Pflug wrote:
> Sounds good. That'll also give me some time to test the RI trigger
> infrastructure now that I've removed the crosscheck code.
Ok, I've found some time do run some additional tests.
I've created a small test suite to compare the behaviour of native
Fujii Masao writes:
> On Fri, Aug 6, 2010 at 11:02 PM, Tom Lane wrote:
>> The initial value needs to be small until we have been able to probe
>> rlimit and figure out what is safe.
> Thanks! How about adding the comment about that as follows?
I added this:
/*
* We use the hopefully-
"Kevin Grittner" wrote:
> With only ten days to go, in order to leave time for committers to
> do their thing, we need to be wrapping up the remaining patches.
> I think we look pretty good. Of the remaining six patches, two
> are Work in Progress, so are not expected to go to a committer;
> t
On Fri, Aug 6, 2010 at 10:10 PM, Alanoly Andrews wrote:
> I’m testing “hot standby” using “streaming WAL records”. On trying to bring
> up the hot standby, I see the following error in the log:
Thanks for the report!
> LOG: database system was interrupted; last known up at 2010-08-05 14:46:36
>
On Fri, Aug 6, 2010 at 11:02 PM, Tom Lane wrote:
> Fujii Masao writes:
>> The document says that the max_stack_depth is 2MB by default.
>> OTOH, in the source code, the variable max_stack_depth is
>> initialized with 100 (kB), and guc.c also uses 100 as the
>> default. Why?
>
> The initial value
On 06/08/10 15:08, Andrew Dunstan wrote:
On 08/06/2010 02:29 AM, Pavel Stehule wrote:
2010/8/6 David Fetter:
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstan:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('cim30400'::text,
$$http://
On 08/06/2010 02:29 AM, Pavel Stehule wrote:
2010/8/6 David Fetter:
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstan:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('cim30400'::text,
$$http://www.w3.org/1999/XSL/Transform";
version="1.0"
Fujii Masao writes:
> The document says that the max_stack_depth is 2MB by default.
> OTOH, in the source code, the variable max_stack_depth is
> initialized with 100 (kB), and guc.c also uses 100 as the
> default. Why?
The initial value needs to be small until we have been able to probe
rlimit a
On 06/08/10 12:31, Robert Haas wrote:
Maybe there should be
xml_is_well_formed()
xml_is_well_formed_document()
xml_is_well_formed_content()
I agree that consistency with SQL/XML is desirable, but for someone
coming from the outside, the unqualified claim that 'foo' is well-formed
XML might sou
Hi,
The document says that the max_stack_depth is 2MB by default.
OTOH, in the source code, the variable max_stack_depth is
initialized with 100 (kB), and guc.c also uses 100 as the
default. Why?
This seems confusing to me though I know that
InitializeGUCOptions() sets max_stack_depth to 2MB.
Re
On Fri, Aug 6, 2010 at 4:28 AM, Mike Fowler wrote:
> On 03/08/10 16:15, Peter Eisentraut wrote:
>>
>> On lör, 2010-07-31 at 13:40 -0400, Robert Haas wrote:
Well-formedness should probably only allow XML documents.
>>>
>>> I think the point of this function is to determine whether a cast
On Fri, 2010-08-06 at 16:26 +0800, Boxuan Zhai wrote:
> So, we need to add both DO NOTHING and RAISE ERROR actions in the
> MERGE command now !? What will RAISE ERROR do?
Let's get the rest of it working first. This would be a later extension,
though I think an important one for our developers.
On 03/08/10 16:15, Peter Eisentraut wrote:
On lör, 2010-07-31 at 13:40 -0400, Robert Haas wrote:
Well-formedness should probably only allow XML documents.
I think the point of this function is to determine whether a cast to
xml will throw an error. The behavior should probably match exactly
w
On Fri, Aug 6, 2010 at 3:53 PM, Simon Riggs wrote:
> On Fri, 2010-08-06 at 10:28 +0300, Heikki Linnakangas wrote:
> > On 06/08/10 10:12, Simon Riggs wrote:
> > > So DO NOTHING is the default and implies silently ignoring rows. RAISE
> > > ERROR is the opposite.
> > >
> > > Coding for those seems
On Fri, Aug 6, 2010 at 3:41 PM, Simon Riggs wrote:
> On Fri, 2010-08-06 at 10:28 +0300, Heikki Linnakangas wrote:
>
> > > SQL:2011 makes no mention of how MERGE should react to statement level
> > > triggers. MERGE is not a trigger action even. Given considerable
> > > confusion in this area, IMH
On 06/08/10 05:38, Peter Eisentraut wrote:
On tis, 2010-07-27 at 16:33 -0700, David Fetter wrote:
* Do we already have it?
Not really. There are kludges to accomplish these things, but
they're available mostly in the sense that a general-purpose
language allows you to write
1 - 100 of 111 matches
Mail list logo
