On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstan and...@dunslane.net:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('employeenamecim/nameage30/agepay400/pay/employee'::text,
$$xsl:stylesheet
2010/8/6 David Fetter da...@fetter.org:
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstan and...@dunslane.net:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
xslt_process('employeenamecim/nameage30/agepay400/pay/employee'::text,
$$xsl:stylesheet
On 06/08/10 04:39, Boxuan Zhai wrote:
I have seen a lively discussion about the DO NOTING action in MERGE command.
And, I think most people want it. So it will be added to my next patch.
Before the implementation, I still have some questions to confirm:
1. If we have a DO NOTHING action
On Fri, 2010-08-06 at 09:39 +0800, Boxuan Zhai wrote:
Besides, (I mean no offense, but) can this method really avoid losing
row?
Not as you just specified, no.
You need *both* actions of RAISE ERROR and DO NOTHING, or you may as
well have neither.
(1) Natural style allows missing rows if
http://groups.yahoo.com/group/igodsinkma/message
die ihre Stellung als Herren der Erde nur der Genialitat und dem Mute
verdanken, mit dem sie sich diese
zu erkampfen und zu wahren wissen; vor unserer deutschen
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 very easy, its just a question of should we do
it?. DB2 has it; SQL:2008 does not. But then SQL:2008 followed the DB2
introduction of AND
On 06/08/10 01:13, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 08/05/2010 05:11 PM, Tom Lane wrote:
This example doesn't seem terribly compelling. Why would you bother
using USING with constants?
In a more complex example you might use $1 in more than one place in the
On 06/08/10 01:13, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
On 08/05/2010 05:11 PM, Tom Lane wrote:
This example doesn't seem terribly compelling. Why would you bother
using USING with constants?
In a more complex example you might use $1 in more than one place in the
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, IMHO we should just say the MERGE does not call
statement triggers
On Thu, 2010-08-05 at 19:39 +0300, Heikki Linnakangas wrote:
On 05/08/10 18:43, Simon Riggs wrote:
Do we still need me to work on concurrent MERGE, or is that included in
the current MERGE patch (can't see it), or ...
It's not in the current MERGE patch.
OK, I will work on it, eventually,
On 4 August 2010 15:08, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi wrote:
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010 14:43, Marko Tiikkajamarko.tiikk...@cs.helsinki.fi
wrote:
I'm not sure I understand. RETURNING in DELETE on a table fetches the
old
value after it was
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 very easy, its just a question of should we do
it?. DB2 has it;
aoa how can i connect my postgres database to manifold?
Regards?
On Fri, Aug 6, 2010 at 12:49 PM, Dean Rasheed dean.a.rash...@gmail.comwrote:
On 4 August 2010 15:08, Marko Tiikkaja marko.tiikk...@cs.helsinki.fi
wrote:
On 8/4/10 5:03 PM +0300, Dean Rasheed wrote:
On 4 August 2010
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
On Fri, Aug 6, 2010 at 3:41 PM, Simon Riggs si...@2ndquadrant.com 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
On Fri, Aug 6, 2010 at 3:53 PM, Simon Riggs si...@2ndquadrant.com 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
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
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 Fri, Aug 6, 2010 at 4:28 AM, Mike Fowler m...@mlfowler.com 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
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.
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
Fujii Masao masao.fu...@gmail.com 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
On 08/06/2010 02:29 AM, Pavel Stehule wrote:
2010/8/6 David Fetterda...@fetter.org:
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstanand...@dunslane.net:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
On 06/08/10 15:08, Andrew Dunstan wrote:
On 08/06/2010 02:29 AM, Pavel Stehule wrote:
2010/8/6 David Fetterda...@fetter.org:
On Fri, Aug 06, 2010 at 05:57:37AM +0200, Pavel Stehule wrote:
2010/8/6 Andrew Dunstanand...@dunslane.net:
On 08/05/2010 06:56 PM, Mike Fowler wrote:
SELECT
On Fri, Aug 6, 2010 at 11:02 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Fujii Masao masao.fu...@gmail.com 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
On Fri, Aug 6, 2010 at 10:10 PM, Alanoly Andrews alano...@invera.com 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Fujii Masao masao.fu...@gmail.com writes:
On Fri, Aug 6, 2010 at 11:02 PM, Tom Lane t...@sss.pgh.pa.us 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:
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
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:
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
On Fri, Aug 6, 2010 at 11:36 AM, Alvaro Herrera
alvhe...@commandprompt.com 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:
Mike Fowler m...@mlfowler.com writes:
SELECT
xslt_process( ... , ... ,
'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
produces
samples
samplev1/sample
samplev2/sample
samplev3/sample
samplev4/sample
samplev5/sample
/samples
Sadly I get the following in both
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]. I
On Fri, Aug 6, 2010 at 12:26 PM, Simon Riggs si...@2ndquadrant.com 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.
verb SECURITY LABEL? verb = CREATE, ADD, ...
Can't objects have more than one label?
How
Hello
attached updated patch with regression test
2010/8/6 Tom Lane t...@sss.pgh.pa.us:
Mike Fowler m...@mlfowler.com writes:
SELECT
xslt_process( ... , ... ,
'n1=v1,n2=v2,n3=v3,n4=v4,n5=v5'::text)
produces
samples
samplev1/sample
samplev2/sample
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
On Thu, Aug 5, 2010 at 7:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Andrew Dunstan and...@dunslane.net 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
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 5, 2010 at 7:05 PM, Tom Lane t...@sss.pgh.pa.us 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
2010/8/6 Tom Lane t...@sss.pgh.pa.us:
Andrew Dunstan and...@dunslane.net 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
On Fri, Aug 6, 2010 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Thu, Aug 5, 2010 at 7:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
One thing that I find rather distressing about this is the 25% bloat
in sizeof(SharedInvalidationMessage). Couldn't
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
Pavel Stehule pavel.steh...@gmail.com writes:
2010/8/6 Tom Lane t...@sss.pgh.pa.us:
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
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 6, 2010 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us 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
2010/8/6 Robert Haas robertmh...@gmail.com:
On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule pavel.steh...@gmail.com 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
On Fri, Aug 6, 2010 at 12:50 PM, Robert Haas robertmh...@gmail.com 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?
--
Robert Haas robertmh...@gmail.com 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
Jaime Casanova ja...@2ndquadrant.com writes:
On Fri, Aug 6, 2010 at 12:50 PM, Robert Haas robertmh...@gmail.com 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
Andres Freund and...@anarazel.de 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
On Fri, Aug 6, 2010 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 6, 2010 at 1:14 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Really? Surely that should be illegal during normal operation. We
might be doing such during crash recovery, but we
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.
Pavel Stehule pavel.steh...@gmail.com 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')
On Fri, Aug 6, 2010 at 2:16 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Jaime Casanova ja...@2ndquadrant.com writes:
On Fri, Aug 6, 2010 at 12:50 PM, Robert Haas robertmh...@gmail.com wrote:
Just DROP TABLE pg_temp_2.foo or whatever and away you go.
wow! that's true... and certainly a bug...
No,
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 6, 2010 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us 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).
Robert Haas robertmh...@gmail.com 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
On Fri, Aug 06, 2010 at 03:00:35PM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
David Fetter da...@fetter.org 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
2010/8/6 Tom Lane t...@sss.pgh.pa.us:
Pavel Stehule pavel.steh...@gmail.com 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
On Fri, Aug 6, 2010 at 3:00 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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 Fri, Aug 6, 2010 at 2:43 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 6, 2010 at 2:07 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Sure, it tops out somewhere, but 32K is way too close to configurations
we know work well enough in the field (I've
On 06/08/10 17:31, Fujii Masao wrote:
On Fri, Aug 6, 2010 at 10:10 PM, Alanoly Andrewsalano...@invera.com 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 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 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
On Friday 06 August 2010 20:23:15 Tom Lane wrote:
Andres Freund and...@anarazel.de 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...
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 it
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, are
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
2010/8/6 David E. Wheeler da...@kineticode.com:
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
2010/8/6 Peter Eisentraut pete...@gmx.net:
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
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 mailing
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)
That will make
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 you can
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 TYPE
On Fri, Aug 6, 2010 at 1:46 PM, Pavel Stehule pavel.steh...@gmail.com 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
On mån, 2010-07-26 at 10:46 -0600, Alex Hunsaker wrote:
On Sat, Jul 24, 2010 at 06:23, Peter Eisentraut pete...@gmx.net 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.
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
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
2010/8/6 David E. Wheeler da...@kineticode.com:
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
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:
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 foo(this :=
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= wulc...@wulczer.org 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.)
On Fri, Aug 6, 2010 at 4:52 PM, Peter Eisentraut pete...@gmx.net 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');
Peter Eisentraut pete...@gmx.net 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
David E. Wheeler da...@kineticode.com 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
David E. Wheeler david.whee...@pgexperts.com 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
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 top? I
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
David E. Wheeler david.whee...@pgexperts.com 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
David E. Wheeler david.whee...@pgexperts.com 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
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 any
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 6, 2010 at 6:49 PM, David E. Wheeler
david.whee...@pgexperts.com 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)
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
2010/7/26 Robert Haas robertmh...@gmail.com:
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
On Aug 6, 2010, at 4:31 PM, Kris Jurka wrote:
binary-copy-end-v2.patch
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
2010/8/7 Gordon Shannon gordo...@gmail.com:
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
On Fri, Aug 6, 2010 at 9:11 PM, Itagaki Takahiro
itagaki.takah...@gmail.com wrote:
2010/8/7 Gordon Shannon gordo...@gmail.com:
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
Peter Eisentraut pete...@gmx.net 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
(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
1 - 100 of 112 matches
Mail list logo
