On Sun, 2011-01-16 at 16:30 -0800, Ron Mayer wrote:
> Tom Lane wrote:
> > Simon Riggs writes:
> >> It's a major undertaking trying to write software that runs against
> >> PostgreSQL for more than one release. We should be making that easier,
> >> not harder.
> >
> > None of the proposals would m
Tom Lane wrote:
> Simon Riggs writes:
>> It's a major undertaking trying to write software that runs against
>> PostgreSQL for more than one release. We should be making that easier,
>> not harder.
>
> None of the proposals would make it impossible to write a LOCK statement
> that works on all av
Tom Lane writes:
> Another possibility is to disallow just the single case
> LOCK tablename NOWAIT
> ie, you can write NOWAIT if you include *either* the object type
> or the IN...MODE clause. This is not too hard as far as the grammar
> is concerned, but I'm not exactly sure how to documen
Robert Haas writes:
> Do we wish to officially document LOCK without TABLE as a good idea to
> start avoiding, in case we decide to do something about that in the
> future?
I'm still not for fixing the ambiguity that way. TABLE is an optional
noise word in other contexts, notably GRANT/REVOKE wh
On Sat, Jan 15, 2011 at 3:37 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 15, 2011 at 10:25 AM, Tom Lane wrote:
>>> I suggest also marking each item with a release in which we intend to do
>>> it, so we don't have to try to remember whether a reasonable amount of
>>> time has elapsed
Robert Haas writes:
> On Sat, Jan 15, 2011 at 10:25 AM, Tom Lane wrote:
>> I suggest also marking each item with a release in which we intend to do
>> it, so we don't have to try to remember whether a reasonable amount of
>> time has elapsed.
> You mean like the way the 9.1devel documentation sa
On Sat, Jan 15, 2011 at 10:25 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Sat, Jan 15, 2011 at 6:29 AM, Simon Riggs wrote:
>>> I think we should have a section in the release notes on Deprecated
>>> Features, noting that certain things will be removed later and should be
>>> changed now and
Robert Haas writes:
> On Sat, Jan 15, 2011 at 6:29 AM, Simon Riggs wrote:
>> I think we should have a section in the release notes on Deprecated
>> Features, noting that certain things will be removed later and should be
>> changed now and not relied upon in the future. A pending
>> incompatibili
On Sat, Jan 15, 2011 at 6:29 AM, Simon Riggs wrote:
> On Sat, 2011-01-15 at 12:19 +0100, Florian Pflug wrote:
>> On Jan15, 2011, at 02:03 , Tom Lane wrote:
>> > Robert Haas writes:
>> >> Me, too. But I don't agree with your particular choice of small
>> >> syntax adjustment. Maybe we should jus
On Jan 15, 2011 12:30 PM, "Simon Riggs" wrote:
>
> On Sat, 2011-01-15 at 12:19 +0100, Florian Pflug wrote:
> > On Jan15, 2011, at 02:03 , Tom Lane wrote:
> > > Robert Haas writes:
> > >> Me, too. But I don't agree with your particular choice of small
> > >> syntax adjustment. Maybe we should ju
On Sat, 2011-01-15 at 12:19 +0100, Florian Pflug wrote:
> On Jan15, 2011, at 02:03 , Tom Lane wrote:
> > Robert Haas writes:
> >> Me, too. But I don't agree with your particular choice of small
> >> syntax adjustment. Maybe we should just let the issue drop for now.
> >> Nobody's actually compla
On Jan15, 2011, at 02:03 , Tom Lane wrote:
> Robert Haas writes:
>> Me, too. But I don't agree with your particular choice of small
>> syntax adjustment. Maybe we should just let the issue drop for now.
>> Nobody's actually complained about this that I can recall; it's just a
>> comment that's b
On Fri, 2011-01-14 at 17:34 -0500, Tom Lane wrote:
>
> > I'm not keen to explain to people how we broke their applications
> just
> > because we wanted to add new functionality AND avoid one
> shift/reduce
> > conflict in our SQL grammar. Avoiding changes to user code isn't
> third
> > on that lis
Robert Haas writes:
> Me, too. But I don't agree with your particular choice of small
> syntax adjustment. Maybe we should just let the issue drop for now.
> Nobody's actually complained about this that I can recall; it's just a
> comment that's been sitting there in pg_dump for ages, and I was
On Fri, Jan 14, 2011 at 5:34 PM, Tom Lane wrote:
>> I'm not keen to explain to people how we broke their applications just
>> because we wanted to add new functionality AND avoid one shift/reduce
>> conflict in our SQL grammar. Avoiding changes to user code isn't third
>> on that list of three thi
Simon Riggs writes:
> On Fri, 2011-01-14 at 16:09 -0500, Tom Lane wrote:
>> I think the realistic options are (1) change the syntax
>> non-backward-compatibly or (2) don't add any functionality here.
> (3) think of another way.
The only third way that I can see is to invent some new, unrelated
s
Simon Riggs writes:
> It's a major undertaking trying to write software that runs against
> PostgreSQL for more than one release. We should be making that easier,
> not harder.
None of the proposals would make it impossible to write a LOCK statement
that works on all available releases, so I thin
On Fri, 2011-01-14 at 16:09 -0500, Tom Lane wrote:
> I think the realistic options are (1) change the syntax
> non-backward-compatibly or (2) don't add any functionality here.
(3) think of another way.
I'm not keen to explain to people how we broke their applications just
because we wanted to ad
I wrote:
> It looks to me like the reason why there's a shift/reduce conflict is
> not so much that TABLE is optional as that we allow the syntax
> LOCK tablename NOWAIT
BTW, I did confirm this to the extent of showing that the shift-reduce
conflict could be eliminated by attaching precedenc
On Fri, 2011-01-14 at 15:46 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
> >> No, that will not work at all. LOCK has to be a utility command.
>
> > But it doesn't break the use case for locking sequences, ISTM.
>
> You haven't stated what
Simon Riggs writes:
> On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
>> No, that will not work at all. LOCK has to be a utility command.
> But it doesn't break the use case for locking sequences, ISTM.
You haven't stated what you think that use case is, but in any case
I'm sure someone can
On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
> Simon Riggs writes:
> > On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
> >> In any case I'd rather break apps using "LOCK foo NOWAIT" than break
> >> every application using any form of LOCK at all, which is what I think
> >> your proposal w
Simon Riggs writes:
> On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
>> In any case I'd rather break apps using "LOCK foo NOWAIT" than break
>> every application using any form of LOCK at all, which is what I think
>> your proposal will amount to in practice.
> Can I suggest that we don't br
On Fri, 2011-01-14 at 14:48 -0500, Tom Lane wrote:
> In any case I'd rather break apps using "LOCK foo NOWAIT" than break
> every application using any form of LOCK at all, which is what I think
> your proposal will amount to in practice.
Can I suggest that we don't break anything at all?
pg_lo
Le 14 janv. 2011 à 20:08, Robert Haas a écrit :
> On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane wrote:
>
>> So it looks to me like there are at least two fixes other than the ones
>> you enumerated:
>>
>> 1. Make NOWAIT a reserved word. Not good, but perhaps better than
>> reserving all the diffe
Robert Haas writes:
> On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane wrote:
>> 2. Disallow the above abbreviated syntax; allow NOWAIT only after an
>> explicit IN ... MODE phrase. This would probably break a couple of
>> applications, but I bet a lot fewer than changing the longer-established
>> part
On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane wrote:
> Robert Haas writes:
>> Tom - I am willing to implement this if you think it's valuable, but
>> I'd like your input on the syntax.
>> http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
>
> It looks to me like the reason why there's
On Fri, 2011-01-14 at 13:58 -0500, Tom Lane wrote:
> Robert Haas writes:
> > Tom - I am willing to implement this if you think it's valuable, but
> > I'd like your input on the syntax.
> > http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
>
> It looks to me like the reason why the
Robert Haas writes:
> Tom - I am willing to implement this if you think it's valuable, but
> I'd like your input on the syntax.
> http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
It looks to me like the reason why there's a shift/reduce conflict is
not so much that TABLE is optio
On Tue, Jan 11, 2011 at 8:31 PM, Robert Haas wrote:
> In that case, can I have some comments on approaches mentioned in my OP?
Tom - I am willing to implement this if you think it's valuable, but
I'd like your input on the syntax.
http://archives.postgresql.org/pgsql-hackers/2011-01/msg00472.php
On Tue, Jan 11, 2011 at 10:35 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii wrote:
>>> For query based replication tools like pgpool-II (I don't know any
>>> other tools, for example Postgres XC falls in this category or
>>> not...), we need to be abl
> In the SEQUENCE example above, SELECT ... FOR UPDATE is certainly not
> adequate to protect the sequence against DDL-level changes. Fortunately
> sequences don't have too many DDL commands, but still an ALTER RENAME
> might be enough to confuse pg_dump.
>
> (By the way, does that SELECT ... FOR
Robert Haas writes:
> On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii wrote:
>> For query based replication tools like pgpool-II (I don't know any
>> other tools, for example Postgres XC falls in this category or
>> not...), we need to be able to lock sequences. Fortunately it is allowed to:
>>
>>
On Tue, Jan 11, 2011 at 6:31 AM, Tatsuo Ishii wrote:
>>> For query based replication tools like pgpool-II (I don't know any
>>> other tools, for example Postgres XC falls in this category or
>>> not...), we need to be able to lock sequences. Fortunately it is allowed to:
>>>
>>> SELECT 1 FROM foo_
> On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii wrote:
>>> On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug wrote:
I forgot about sequences earlier. If we dump while someone deletes all
rows and resets the sequence the dump might contain rows and still
reset the sequence. This could c
On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii wrote:
>> On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug wrote:
>>> I forgot about sequences earlier. If we dump while someone deletes all
>>> rows and resets the sequence the dump might contain rows and still
>>> reset the sequence. This could cause d
At present, XC does not seem to need locks to maintain cluster-wide
integrity because it is maintained centrally in GTM. If application
needs to do this, for example, to synchronize between different
clusters, XC needs this capability obviously.
--
Koichi Suzuki
2011/1/11 Tatsuo Ishii :
> On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug wrote:
>> I forgot about sequences earlier. If we dump while someone deletes all
>> rows and resets the sequence the dump might contain rows and still
>> reset the sequence. This could cause duplicate key errors on restore.
>> I haven't checked if th
On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug wrote:
> I forgot about sequences earlier. If we dump while someone deletes all
> rows and resets the sequence the dump might contain rows and still
> reset the sequence. This could cause duplicate key errors on restore.
> I haven't checked if this is
On Jan7, 2011, at 23:56 , Robert Haas wrote:
> On Fri, Jan 7, 2011 at 5:17 PM, Florian Pflug wrote:
>> Thus, all objects which are dumped purely by SQL-level inspection of the
>> system catalogs are safe I think. This is true for most objects I guess,
>> with the important exception being dumping
On Fri, Jan 7, 2011 at 5:17 PM, Florian Pflug wrote:
> On Jan7, 2011, at 22:21 , Robert Haas wrote:
>> So suppose you pg_dump a view and and a function that uses the view.
>> In the middle of the dump, someone alters the view and the function in
>> a single transaction and commits it. You might d
On Jan7, 2011, at 22:21 , Robert Haas wrote:
> So suppose you pg_dump a view and and a function that uses the view.
> In the middle of the dump, someone alters the view and the function in
> a single transaction and commits it. You might dump the function
> before the transaction commits and the v
On Fri, Jan 7, 2011 at 12:17 PM, Simon Riggs wrote:
> On Fri, 2011-01-07 at 08:16 -0500, Robert Haas wrote:
>
>> One of the things that I ripped out of the SQL/MED syntax patch before
>> committing it was the hack that made LOCK TABLE also work on FOREIGN
>> TABLEs. Since we're treating a foreign
On Fri, 2011-01-07 at 08:16 -0500, Robert Haas wrote:
> One of the things that I ripped out of the SQL/MED syntax patch before
> committing it was the hack that made LOCK TABLE also work on FOREIGN
> TABLEs. Since we're treating a foreign table as a different kind of
> object than a TABLE in some
On Fri, Jan 07, 2011 at 10:58:41AM -0500, Robert Haas wrote:
> On Fri, Jan 7, 2011 at 10:52 AM, David Fetter wrote:
> > I'm not sure I understand this. Does it mean I'd have to say
> >
> > LOCK TABLE my_view;
>
> No.
+1 for #4, then :)
Cheers,
David.
--
David Fetter http://fetter.org/
Pho
On Fri, Jan 7, 2011 at 10:52 AM, David Fetter wrote:
> I'm not sure I understand this. Does it mean I'd have to say
>
> LOCK TABLE my_view;
No.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@
On Fri, Jan 07, 2011 at 08:16:33AM -0500, Robert Haas wrote:
> One of the things that I ripped out of the SQL/MED syntax patch before
> committing it was the hack that made LOCK TABLE also work on FOREIGN
> TABLEs. Since we're treating a foreign table as a different kind of
> object than a TABLE i
One of the things that I ripped out of the SQL/MED syntax patch before
committing it was the hack that made LOCK TABLE also work on FOREIGN
TABLEs. Since we're treating a foreign table as a different kind of
object than a TABLE in some places, we shouldn't confuse the two
things elsewhere, at leas
48 matches
Mail list logo
