Tom == Tom Lane t...@sss.pgh.pa.us writes:
David E. Wheeler da...@kineticode.com writes:
... I think that this patch is ready for committer review and, perhaps,
committing. The code looks clean (though mainly over my head) and the
functionality is top-notch.
Tom Given the number of
Mitani-San,
thank you for this heads up on PGCluster-II. The partial data idea
sounds very interesting and I'm looking forward to an inspiring meeting
in Tokyo.
Kind Regards
Markus Wanner
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
On Sun, Sep 20, 2009 at 05:59, Abhijit Menon-Sen a...@toroid.org wrote:
I think the patch is more or less ready, but I have a few minor
comments:
First, it needs to be reformatted to not use a space before the opening
parentheses in (some) function calls and definitions.
***
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Andrew Dunstan and...@dunslane.net writes:
Really? That wasn't my expectation at all. I expected that the code
would in effect be always returning void. I think you're moving the
goalposts a bit here. I don't think we need a RETURNS clause on it for
Robert Haas robertmh...@gmail.com writes:
That doesn't seem appropriate. Returned With Feedback means that the
patch is dead as far as this CommitFest goes, which isn't what you
seem to be saying at all. I think this should stay Needs Review until
it's had a full review, and then we can
Andrew Gierth wrote:
I'd appreciate public feedback on:
- whether conversions to/from a {key,val,key,val,...} array are needed
(and if there's strong opinions in favour of making them casts; in the
absence of strong support for that, I'll stick to functions)
Strikes me as an
(This is a partial review of the grantonall-20090810v2.diff patch posted
by Petr Jelinek on 2009-08-10 (hi PJMODOS!). See
http://archives.postgresql.org/message-id/4a7f5853.5010...@pjmodos.net
for the original message.)
I have not yet been able to do a complete review of this patch, but I am
2009/9/20 Dimitri Fontaine dfonta...@hi-media.com:
Hi,
Tom Lane t...@sss.pgh.pa.us writes:
Andrew Dunstan and...@dunslane.net writes:
Really? That wasn't my expectation at all. I expected that the code
would in effect be always returning void. I think you're moving the
goalposts a bit here.
Ron Mayer rm...@cheapcomplexdevices.com writes:
Andrew Gierth wrote:
- what to do when installing the new version's .sql into an existing db;
the send/recv support and some of the index support doesn't get installed
if the hstore type and opclasses already exist. In the case of an upgrade
(or
At 2009-09-20 20:20:11 +0530, a...@toroid.org wrote:
1. The patch did apply to HEAD and build cleanly, but there are now a
couple of minor (documentation) conflicts.
To be more clear, what I meant is that it did apply and build cleanly
when it was posted, but things have drifted enough now
Robert Haas robertmh...@gmail.com writes:
... A related question is whether we
should replace the CSV option with a FORMAT option for which one
of the possible choices is CSV (much as we did with EXPLAIN).
That might be a good idea --- otherwise we'd need some ad-hoc code
to check that only
Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
... A related question is whether we
should replace the CSV option with a FORMAT option for which one
of the possible choices is CSV (much as we did with EXPLAIN).
That might be a good idea --- otherwise we'd need some ad-hoc
On Sat, 2009-09-19 at 23:15 -0400, Robert Haas wrote:
I was wondering if we couldn't introduce a dummy tuple name similar to
OLD and NEW, called, say, OTHER. Then instead of writing a =, you
could write a = OTHER.a ... or perhaps a = OTHER.b ... although that
might also open the door to more
Emmanuel Cecchet m...@asterdata.com writes:
That would assume that the semantic of the other options (header, quote,
espace, ...) is exactly the same for each format. Otherwise this will be
a nightmare to document.
Well, sure, we should pick a different name for an option that means
On Sat, 2009-09-19 at 19:23 -0700, David Fetter wrote:
It just occurred to me that SQL:2008 ASSERTION might already fit this
feature. :)
I think I would only be able to enforce very specific types of
assertions that match the template. As I said to Robert, I think I'm
going to use ALTER INDEX
Jeff Davis pg...@j-davis.com writes:
On Sat, 2009-09-19 at 18:00 -0400, Tom Lane wrote:
Well, you can't do it *exactly* the same way btree does, but what
I would envision is first insert the index tuple and then do a
dirty-snapshot search for conflicting tuples. The interlock against
Jeff Davis pg...@j-davis.com writes:
I would still really like to decouple this from CREATE INDEX because of
two reasons:
1. Cannot support multiple constraints per index very easily. I think
this is a significant feature.
2. Must decide to make constraint at the same time as making
On Sun, 2009-09-20 at 12:31 -0400, Tom Lane wrote:
T1: inserts into index
T2: inserts into index
T1: checks index for conflicts, finds T2
T2: checks index for conflicts, finds T1
You get a deadlock failure, because both transactions will wait for each
other. So what? It's an error in
On Wed, 2009-09-16 at 13:47 +0900, Itagaki Takahiro wrote:
Peter Eisentraut pete...@gmx.net wrote:
This patch is listed in the commitfest, but I think the consensus was
that it needed some rework.
No doubt, but SQL/MED will require a lot of works. Can we split the work
into small parts?
Fujii Masao wrote:
On Fri, Sep 18, 2009 at 7:34 PM, Fujii Masao masao.fu...@gmail.com wrote:
This approach is OK if the stand-alone walreceiver is treated steadily
by the startup process like a child process under postmaster:
* Handling of some interrupts: SIGHUP, SIGTERM?, SIGINT, SIGQUIT...
BTW, I just thought of an issue that might change some of these
conclusions: what about supporting deferred constraint checking,
as we just recently managed to do for straight UNIQUE constraints?
I don't say that this has to be in the first cut, but it's something
we ought to try to leave room for
On Sun, 2009-09-20 at 12:45 -0400, Tom Lane wrote:
How often have we had requests to add or drop UNIQUE in an existing
index? Maybe there were more than zero, but not by a lot.
Ok.
As an example of why I don't believe the first item, consider something
like
create index ... (a = , b
On Sun, 2009-09-20 at 13:01 -0400, Tom Lane wrote:
The current infrastructure for deferred uniqueness requires that the
thing actually be a constraint, with an entry in pg_constraint that
can carry the deferrability options. So unless we want to rethink
that, this might be a sufficient reason
Jeff Davis pg...@j-davis.com writes:
My use case was something else:
An index on (a, b, c) enforcing the constraints UNIQUE(a, b) and
UNIQUE(a, c).
UNIQUE(a, b) can be enforced efficiently. UNIQUE(a, c) might be less
efficient depending on the selectivity of a, but as long as a is
Jeff Davis pg...@j-davis.com writes:
So, do I still omit it from information_schema?
My thought is yes --- any representation of it within information_schema
would be so inaccurate/incomplete as to be worse than useless, IMO.
Peter might have a different idea though ...
On Sun, 2009-09-20 at 13:13 -0400, Tom Lane wrote:
You're right, it still seems remarkably marginal. I'm rethinking
my position on use of CONSTRAINT syntax because of the deferrability
issue, but I'm still unconvinced that we need to allow the constraints
to be decoupled from the indexes.
Jeff Davis pg...@j-davis.com writes:
On Sun, 2009-09-20 at 13:13 -0400, Tom Lane wrote:
You're right, it still seems remarkably marginal. I'm rethinking
my position on use of CONSTRAINT syntax because of the deferrability
issue, but I'm still unconvinced that we need to allow the constraints
On Sun, 2009-09-20 at 13:28 -0400, Tom Lane wrote:
What I'm arguing for is a syntax in which the question doesn't even
arise, ie, a CONSTRAINT doesn't reference an existing index at all.
If that's not possible for whatever reason, then I think that
disallowing multiple references isn't going
Jeff Davis pg...@j-davis.com writes:
I believe that syntax is possible by specifying the index access method,
e.g.:
CONSTRAINT name EXCLUSION (a =, b ) USING gist;
versus:
CONSTRAINT name EXCLUSION (a =, b ) INDEX indexname;
And the former could build the index implicitly. I haven't
Tom Lane wrote:
No, I don't think so. Suppose I write
COPY ... (xml_header on)
If HEADER isn't actually an option supported by XML format, what I will
get here is an unknown option error, which conveys just about nothing
--- is it really an unsupported combination, or did I just
Emmanuel Cecchet m...@asterdata.com writes:
Here you will force every format to use the same set of options
How does this force any such thing?
and if
someone introduces a new option, you will have to modify all other
formats to make sure they throw an error telling the user that this
Tom Lane wrote:
Emmanuel Cecchet m...@asterdata.com writes:
Here you will force every format to use the same set of options
How does this force any such thing?
As far as I understand it, every format will have to handle every format
options that may exist so that they can either
Emmanuel Cecchet m...@asterdata.com writes:
So maybe a tradeoff is to differentiate format specific options like in:
(delimiter '.', format csv, format_header, format_escape...)
This should also make clear if someone develops a new format what
options need to be addressed.
I think that
On Sep 18, 2009, at 6:27 PM, Andrew Gierth wrote:
However, I would prefer to keep the ability to do this:
psql --set hstore_schema='myschema' -f hstore.sql dbname
The logic to do it is a bit ugly, but editing the file to set what
schema to
use is even uglier...
Yes, this should perhaps
On Sep 20, 2009, at 8:43 AM, Tom Lane wrote:
If the perfect solution is too complex, I'd also kinda hope this
isn't a
show-stopper for this patch, but rather a TODO for the future
modules feature.
Yeah, this is a long-standing generic issue, and not really hstore's
problem to fix.
So
On Sep 20, 2009, at 1:03 AM, Andrew Gierth wrote:
I will resubmit (hopefully in a day or two) with the following
changes:
- removal of the \set schema variable stuff from the .sql script
- documentation fixes as mentioned in my previous email
- additional documentation for some of the newer
David E. Wheeler da...@kineticode.com writes:
On Sep 20, 2009, at 8:43 AM, Tom Lane wrote:
Yeah, this is a long-standing generic issue, and not really hstore's
problem to fix.
So then does there need to be some documentation for how to deal with
this, for those doing an in-place upgrade
On Sun, 2009-09-20 at 13:49 -0400, Tom Lane wrote:
I'd vote for only supporting the former.
Ok.
I just did some brief non-scientific in-memory benchmarks. I think it
has promise, but for now I think it can safely be set aside.
Results appended.
What worries me more about that syntax is the
Tom Lane t...@sss.pgh.pa.us writes:
But anyhow I think we have run through all the arguments, and it's
time for some votes from other people.
Same option names whatever the format please. We know the context is
important and people will be able to understand that header does not
refer exactly
Tom Lane t...@sss.pgh.pa.us writes:
I believe we have already discussed the necessity for pg_upgrade to
support this type of subterfuge. A module facility would be a lot
better of course, but we still need something for upgrading existing
databases that don't contain the module structure.
An
Update on operator exclusion constraints (OXC for short):
After a lot of discussion, I think a lot of progress has been made. Here
is my summary, please let me know if I've left anything out or not
addressed some concern.
1. Constraint syntax, part of CREATE/ALTER TABLE:
[CONSTRAINT name]
Jeff Davis pg...@j-davis.com writes:
1. Constraint syntax, part of CREATE/ALTER TABLE:
[CONSTRAINT name] EXCLUSION (expr OPERATOR op, ...)
Have you actually built this grammar? I don't think it avoids the
problem, because OPERATOR is possible within a_expr.
Also, don't forget the
On Sun, Sep 20, 2009 at 2:25 PM, Emmanuel Cecchet m...@asterdata.com wrote:
Tom Lane wrote:
Emmanuel Cecchet m...@asterdata.com writes:
Here you will force every format to use the same set of options
How does this force any such thing?
As far as I understand it, every format will have to
David == David E Wheeler da...@kineticode.com writes:
The only open question I can see is what delete(hs,$1) resolves to
when $1 is an unknown-type placeholder; this is probably an
incompatibility with the old version if anyone is relying on that
(but I don't see why they would be).
On Sun, 2009-09-20 at 17:54 -0400, Tom Lane wrote:
Jeff Davis pg...@j-davis.com writes:
1. Constraint syntax, part of CREATE/ALTER TABLE:
[CONSTRAINT name] EXCLUSION (expr OPERATOR op, ...)
Have you actually built this grammar? I don't think it avoids the
problem, because OPERATOR is
Jeff Davis pg...@j-davis.com writes:
I suppose I should just allow any index_elem. The only way I was able to
make the grammar for that work is by using a reserved keyword. The
possibilities that make the most sense to me are:
index_elem WITH any_operator
index_elem WITH OPERATOR
On Sun, 2009-09-20 at 19:42 -0400, Tom Lane wrote:
BTW, are you sure EXCLUSION doesn't have to become a reserved word for
this? I notice that FOREIGN, CHECK, and UNIQUE all are, which makes me
suspicious ...
All of those (except FOREIGN) can be used as a column constraint as
well, and that
On Tue, Sep 15, 2009 at 7:53 AM, Robert Haas robertmh...@gmail.com wrote:
Consider A IJ B, with
the scan over A implemented as an index scan. It seems to me that if
the join selectivity is 1, then assuming there's a choice, we
probably want to join A to B and then do the heap fetches
On Mon, Sep 14, 2009 at 5:41 AM, Heikki Linnakangas
heikki.linnakan...@enterprisedb.com wrote:
Heikki Linnakangas wrote:
Tom Lane wrote:
It strikes me that in the cases where it wouldn't be necessary to
compute junk sort-key columns, it would be because we were scanning an
index that includes
The easiest for both implementation and documentation might just be to
have a matrix of options.
Each option has a row and a column in the matrix. The intersection of a
row and a column is set to 0 if options are not compatible and set to 1
if it is. This way we are sure to capture all possible
On Thu, Sep 17, 2009 at 4:52 PM, Robert Haas robertmh...@gmail.com wrote:
On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut pete...@gmx.net wrote:
On tor, 2009-09-17 at 11:59 -0500, Kevin Grittner wrote:
Well, in such cases it may be useful to add an option such as
--oknodo to select the
On Fri, Sep 18, 2009 at 4:03 PM, Bernd Helmle maili...@oopsware.de wrote:
--On 25. August 2009 22:17:38 -0400 Alvaro Herrera
alvhe...@commandprompt.com wrote:
I'm just posting in case somebody has thoughts on the UI part of it.
Other things that need fixed:
- need to figure out locking
I think that it is a good idea, but do you can show to us what do you have in
mind with a example?
Regards
The hurry is enemy of the success: for that reason...Be patient
Ing. Marcos L. Ortiz Valmaseda
Línea Soporte y Despliegue
Centro de Tecnologías de Almacenamiento y Análisis de Datos
On Tue, 2009-09-15 at 12:49 +0900, Itagaki Takahiro wrote:
Here is an updated version of the patch.
This is a review of the Eventlog encoding on Windows patch:
http://archives.postgresql.org/message-id/20090915123243.9c59.52131...@oss.ntt.co.jp
Purpose Format
This patch is
Thank you!
-Steve
On Sep 19, 2009, at 6:55 PM, Tom Lane wrote:
Steve Prentice prent...@cisco.com writes:
This patch changes plpgsql IN parameters so they are mutable.
I've applied this, since the consensus seemed to be in favor of it.
I decided not to update the docs for this change
Robert Haas escribió:
Here's a first shot on this for my current review round. Patch needed to
re-merged into current CVS HEAD due to some merge conflicts, i've also
adjusted the regression tests (minor). On a first look, i like the patch
(especially the code for the utility commands
56 matches
Mail list logo
