Hi,
On Sat, Sep 19, 2009 at 1:52 AM, Brendan Jurd wrote:
> 2009/9/19 Tom Lane :
> > Should we have it throw an error if the input corresponding to a G
> > symbol doesn't match the expected group separator? I'm concerned that
> > that would break applications that work okay today.
> >
>
> It wou
2009/9/6 KaiGai Kohei :
> The attached patch is an update of largeobject access controls.
>
it applies fine (just 3 succeded hunks), compiles and passes
regression tests...
ALTER LARGE OBJECT is working, but now that we can change the owner of
a LO we should be able to see who the actual owner is
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 comman
Thank you!
-Steve
On Sep 19, 2009, at 6:55 PM, Tom Lane wrote:
Steve Prentice 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 because the docs
don't c
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 de
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 Fri, Sep 18, 2009 at 4:03 PM, Bernd Helmle wrote:
>
>
> --On 25. August 2009 22:17:38 -0400 Alvaro Herrera
> 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 for roles; this stuff must be syn
On Thu, Sep 17, 2009 at 4:52 PM, Robert Haas wrote:
> On Thu, Sep 17, 2009 at 4:18 PM, Peter Eisentraut 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 idempotent behavior.
>>>
>>>
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 Mon, Sep 14, 2009 at 5:41 AM, Heikki Linnakangas
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 those values. So if th
On Tue, Sep 15, 2009 at 7:53 AM, Robert Haas 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 against A
>>> a
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
Jeff Davis 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 any_operator
> ind
On Sun, 2009-09-20 at 17:54 -0400, Tom Lane wrote:
> Jeff Davis writes:
> > 1. Constraint syntax, part of CREATE/ALTER TABLE:
>
> > [CONSTRAINT ] EXCLUSION ( OPERATOR , ...)
>
> Have you actually built this grammar? I don't think it avoids the
> problem, because OPERATOR is possible within a_
> "David" == David E Wheeler 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).
David> G
On Sun, Sep 20, 2009 at 2:25 PM, Emmanuel Cecchet wrote:
> Tom Lane wrote:
>> Emmanuel Cecchet 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 forma
Jeff Davis writes:
> 1. Constraint syntax, part of CREATE/ALTER TABLE:
> [CONSTRAINT ] EXCLUSION ( OPERATOR , ...)
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 possibility of wanting a nondefault
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 ] EXCLUSIO
Tom Lane 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 idea would be
Tom Lane 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 to the same proces
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
"David E. Wheeler" 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 from an existi
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 then
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 f
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 be
Emmanuel Cecchet 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 distinction would e
Tom Lane wrote:
Emmanuel Cecchet 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 implement it or th
Emmanuel Cecchet 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
> option is not
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 miss
Jeff Davis writes:
> I believe that syntax is possible by specifying the index access method,
> e.g.:
> CONSTRAINT EXCLUSION (a =, b &&) USING gist;
> versus:
> CONSTRAINT EXCLUSION (a =, b &&) INDEX ;
> And the former could build the index implicitly. I haven't written the
> code yet, b
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 goin
Jeff Davis 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
>> to be de
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 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 ...
regards, tom lane
Jeff Davis 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
> selective I thin
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 rea
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 =
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
Fujii Masao wrote:
> On Fri, Sep 18, 2009 at 7:34 PM, Fujii Masao 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...
>> For exa
On Wed, 2009-09-16 at 13:47 +0900, Itagaki Takahiro wrote:
> Peter Eisentraut 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? I inte
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 a
Jeff Davis 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 the
>
Jeff Davis 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
>> conflicting conc
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
Emmanuel Cecchet 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
something significantly
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 mo
Tom Lane wrote:
Robert Haas 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 th
Robert Haas 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 one format opt
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 no
Ron Mayer 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 a dump/restore from
2009/9/20 Dimitri Fontaine :
> Hi,
>
> Tom Lane writes:
>> Andrew Dunstan 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
(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
posti
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 indepen
Robert Haas 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 decide where it goes f
Hi,
Tom Lane writes:
> Andrew Dunstan 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
>> it to be useful.
Yes it'd b
On Sun, Sep 20, 2009 at 05:59, Abhijit Menon-Sen 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.
>
>> *** a/doc/src/sgml/client-a
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 subscriptio
> "Tom" == Tom Lane writes:
> "David E. Wheeler" 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 questions in your rev
58 matches
Mail list logo
