Robert Haas robertmh...@gmail.com 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,
Tom Lane t...@sss.pgh.pa.us 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
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Sun, 2011-01-16 at 16:30 -0800, Ron Mayer wrote:
Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
On Jan15, 2011, at 02:03 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On Sat, 2011-01-15 at 12:19 +0100, Florian Pflug wrote:
On Jan15, 2011, at 02:03 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On Jan 15, 2011 12:30 PM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2011-01-15 at 12:19 +0100, Florian Pflug wrote:
On Jan15, 2011, at 02:03 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Me, too. But I don't agree with your particular choice of small
syntax
On Sat, Jan 15, 2011 at 6:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Sat, 2011-01-15 at 12:19 +0100, Florian Pflug wrote:
On Jan15, 2011, at 02:03 , Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
Me, too. But I don't agree with your particular choice of small
syntax
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 15, 2011 at 6:29 AM, Simon Riggs si...@2ndquadrant.com 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
On Sat, Jan 15, 2011 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 15, 2011 at 6:29 AM, Simon Riggs si...@2ndquadrant.com wrote:
I think we should have a section in the release notes on Deprecated
Features, noting that certain things will
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 15, 2011 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us 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
On Sat, Jan 15, 2011 at 3:37 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jan 15, 2011 at 10:25 AM, Tom Lane t...@sss.pgh.pa.us 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
On Tue, Jan 11, 2011 at 8:31 PM, Robert Haas robertmh...@gmail.com 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.
Robert Haas robertmh...@gmail.com 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
On Fri, 2011-01-14 at 13:58 -0500, Tom Lane wrote:
Robert Haas robertmh...@gmail.com 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
On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us 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
Le 14 janv. 2011 à 20:08, Robert Haas robertmh...@gmail.com a écrit :
On Fri, Jan 14, 2011 at 1:58 PM, Tom Lane t...@sss.pgh.pa.us 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
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?
Simon Riggs si...@2ndquadrant.com 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
On Fri, 2011-01-14 at 15:05 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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
On Fri, 2011-01-14 at 15:46 -0500, Tom Lane wrote:
Simon Riggs si...@2ndquadrant.com 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
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 precedences
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 add
Simon Riggs si...@2ndquadrant.com 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
Simon Riggs si...@2ndquadrant.com 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
On Fri, Jan 14, 2011 at 5:34 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com 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
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 list of three
On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug f...@phlo.org 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
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 Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii is...@postgresql.org wrote:
On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug f...@phlo.org 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
On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii is...@postgresql.org wrote:
On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug f...@phlo.org 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
On Tue, Jan 11, 2011 at 6:31 AM, Tatsuo Ishii is...@postgresql.org 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
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii is...@postgresql.org 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.
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
On Tue, Jan 11, 2011 at 10:35 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jan 11, 2011 at 4:46 AM, Tatsuo Ishii is...@postgresql.org wrote:
For query based replication tools like pgpool-II (I don't know any
other tools, for example Postgres XC falls
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
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 in
On Fri, Jan 7, 2011 at 10:52 AM, David Fetter da...@fetter.org 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
On Fri, Jan 07, 2011 at 10:58:41AM -0500, Robert Haas wrote:
On Fri, Jan 7, 2011 at 10:52 AM, David Fetter da...@fetter.org 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
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 7, 2011 at 12:17 PM, Simon Riggs si...@2ndquadrant.com 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
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 view
On Fri, Jan 7, 2011 at 5:17 PM, Florian Pflug f...@phlo.org 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
On Jan7, 2011, at 23:56 , Robert Haas wrote:
On Fri, Jan 7, 2011 at 5:17 PM, Florian Pflug f...@phlo.org 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
On Fri, Jan 7, 2011 at 6:28 PM, Florian Pflug f...@phlo.org 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
48 matches
Mail list logo
