Hello.
You wrote:
TL> Pavel Golub writes:
>> Is there any possibility that Postgres will have named transaction
>> ever, like Firebird?
TL> What in heck is a named transaction, and why should we care?
TL> regards, tom lane
Sorry guys, my bad. The thing is I'm not a Fire
On Wed, 2009-06-17 at 16:22 -0400, Greg Sabino Mullane wrote:
> This was failing:
>
> CREATE TRIGGER foo
> AFTER INSERT OR UPDATE OR DELETE OR TRUNCATE
> ON foobar
> FOR EACH STATEMENT EXECUTE PROCEDURE baz();
>
> Turns out the parser wasn't set up to handle four different trigger
> event types.
Itagaki Takahiro wrote:
Peter Eisentraut wrote:
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the cli
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Jun 17, 2009 at 04:32:51PM +0200, Andres Freund wrote:
> On 06/17/2009 04:27 PM, Peter Eisentraut wrote:
>> On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
>>> 1. It didn't seem very wise to go with the approach of trying to do
>>> EVERYTHI
"Greg Sabino Mullane" writes:
> Thanks. I'll leave the [5] restriction call to someone else, seems it
> does no harm to me though (not as if we'd change it that often anyway).
> Revised patch below. I looked through other places that might be affected,
> but did not see anything else except ecpg
Here is an updated version of my "generic options for explain" patch.
Previous version here:
http://archives.postgresql.org/pgsql-hackers/2009-06/msg00866.php
This patch requires the "explain refactoring v4" patch, which you can
find here, to be applied first:
http://archives.postgresql.org/pgsq
Itagaki Takahiro writes:
> Peter Eisentraut wrote:
>> On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
>>> We currently require that you set client_encoding correctly, or you get
>>> garbage in psql and any other tool using libpq. How about setting
>>> client_encoding automatically to
Peter Eisentraut wrote:
> On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
> > We currently require that you set client_encoding correctly, or you get
> > garbage in psql and any other tool using libpq. How about setting
> > client_encoding automatically to match the client's locale?
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
NotDashEscaped: You need GnuPG to verify this message
> ... but this patch doesn't come close to fixing it. struct CreateTrigStmt
> needs changes. I kinda think the restricti
Andrew Dunstan writes:
> According to the (hard to find) Firebird docs (or rather, the old
> Interbase docs, which is all they have):
> A single application can start simultaneous transactions. InterBase
> extends transaction
> management and data manipulation statements to support t
Greg Sabino Mullane writes:
> This was failing:
> CREATE TRIGGER foo
> AFTER INSERT OR UPDATE OR DELETE OR TRUNCATE
> ON foobar
> FOR EACH STATEMENT EXECUTE PROCEDURE baz();
> Turns out the parser wasn't set up to handle four different trigger
> event types.
Hmm, that's a problem ...
> Patch at
On Wed, Jun 17, 2009 at 4:54 PM, Alvaro
Herrera wrote:
> Heikki Linnakangas wrote:
>> We currently require that you set client_encoding correctly, or you get
>> garbage in psql and any other tool using libpq. How about setting
>> client_encoding automatically to match the client's locale? We have
>
On Wed, Jun 17, 2009 at 8:09 PM, Robert Haas wrote:
>
>> I have no idea what they are in Firebird but the name conjured up a
>> different (interesting) idea for me. I had the image of naming a
>> transaction and then being able to have other sessions join that same
>> transaction. We've discussed
This was failing:
CREATE TRIGGER foo
AFTER INSERT OR UPDATE OR DELETE OR TRUNCATE
ON foobar
FOR EACH STATEMENT EXECUTE PROCEDURE baz();
Turns out the parser wasn't set up to handle four different trigger
event types. Patch attached.
--
Greg Sabino Mullane g...@endpoint.com g...@turnstep.com
En
Kevin Grittner wrote:
Tom Lane wrote:
Yes, but some other followups suggest that maybe a "named
transaction" does something else entirely. Thus my request for a
definition of what the OP is actually asking for.
Well, a quick google search suggests that all three guesses here were
Tom Lane wrote:
Andrew Dunstan writes:
Alvaro Herrera wrote:
AFAIK that's an "autonomous transaction", at least to some other RDBMSs.
Right, but since I had to ask what that was recently I though I'd use a
bit more description :-)
Yes, but some other followups sug
On Wed, 2009-06-17 at 14:38 -0500, Kevin Grittner wrote:
> Tom Lane wrote:
>
> > Yes, but some other followups suggest that maybe a "named
> > transaction" does something else entirely. Thus my request for a
> > definition of what the OP is actually asking for.
>
> Well, a quick google searc
Tom Lane wrote:
> Yes, but some other followups suggest that maybe a "named
> transaction" does something else entirely. Thus my request for a
> definition of what the OP is actually asking for.
Well, a quick google search suggests that all three guesses here were
off base. This is the best
Greg Stark wrote:
> On Wed, Jun 17, 2009 at 6:40 PM, Alvaro
> Herrera wrote:
> > AFAIK that's an "autonomous transaction", at least to some other RDBMSs.
>
> I have no idea what they are in Firebird but the name conjured up a
> different (interesting) idea for me. I had the image of naming a
> t
On Wed, Jun 17, 2009 at 3:04 PM, Greg Stark wrote:
> On Wed, Jun 17, 2009 at 6:40 PM, Alvaro
> Herrera wrote:
>> Andrew Dunstan wrote:
>>
>>> Tom Lane wrote:
What in heck is a named transaction, and why should we care?
>>>
>>> Isn't this just another name for a subtransaction or inner transact
On Wed, Jun 17, 2009 at 6:40 PM, Alvaro
Herrera wrote:
> Andrew Dunstan wrote:
>
>> Tom Lane wrote:
>>> What in heck is a named transaction, and why should we care?
>>
>> Isn't this just another name for a subtransaction or inner transaction
>> that can be separately committed?
>
> AFAIK that's an
Andrew Dunstan writes:
> Alvaro Herrera wrote:
>> AFAIK that's an "autonomous transaction", at least to some other RDBMSs.
> Right, but since I had to ask what that was recently I though I'd use a
> bit more description :-)
Yes, but some other followups suggest that maybe a "named transaction"
Alvaro Herrera wrote:
Andrew Dunstan wrote:
Tom Lane wrote:
What in heck is a named transaction, and why should we care?
Isn't this just another name for a subtransaction or inner transaction
that can be separately committed?
AFAIK that's an "autonomous transaction",
Andrew Dunstan wrote:
> Tom Lane wrote:
>> What in heck is a named transaction, and why should we care?
>
> Isn't this just another name for a subtransaction or inner transaction
> that can be separately committed?
AFAIK that's an "autonomous transaction", at least to some other RDBMSs.
--
Al
Tom Lane wrote:
Pavel Golub writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
What in heck is a named transaction, and why should we care?
Isn't this just another name for a subtransaction or inner transact
On Wed, Jun 17, 2009 at 12:25 PM, Guillaume
Smet wrote:
> 2009/6/17 Petr Jelinek :
>> I agree that Default ACLs are more important and I already offered Stephen
>> help on that. But I've seen countless requests for granting on all tables to
>> a user and I already got some positive feedback outside
On Wed, Jun 17, 2009 at 12:41 PM, Greg Stark wrote:
> On 17 Jun 2009, at 17:37, "David E. Wheeler" wrote:
>> On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
>>> Pavel Golub writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
>>> What in heck is a
Greg Stark wrote:
Isn't the answer to grant permissions to a role and then just put
people in that role?
Still have to give permissions at least to that role.
--
Regards
Petr Jelinek (PJMODOS)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
Greg Stark wrote:
>> On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
>>
>>> Pavel Golub writes:
Is there any possibility that Postgres will have named
transaction ever, like Firebird?
>>>
>>> What in heck is a named transaction, and why should we care?
> I'm curious what they ate too
Isn't the answer to grant permissions to a role and then just put
people in that role?
--
Greg
On 17 Jun 2009, at 17:25, Guillaume Smet
wrote:
2009/6/17 Petr Jelinek :
I agree that Default ACLs are more important and I already offered
Stephen
help on that. But I've seen countless requ
I'm curious what they ate too
--
Greg
On 17 Jun 2009, at 17:37, "David E. Wheeler"
wrote:
On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
Pavel Golub writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
What in heck is a named transaction,
On Jun 17, 2009, at 8:08 AM, Tom Lane wrote:
Pavel Golub writes:
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
What in heck is a named transaction, and why should we care?
That Tom Lane, so warm and cuddly!
David
--
Sent via pgsql-hackers mailin
2009/6/17 Petr Jelinek :
> I agree that Default ACLs are more important and I already offered Stephen
> help on that. But I've seen countless requests for granting on all tables to
> a user and I already got some positive feedback outside of the list, so I
> believe there is demand for this. Also t
Heikki Linnakangas wrote:
> We currently require that you set client_encoding correctly, or you get
> garbage in psql and any other tool using libpq. How about setting
> client_encoding automatically to match the client's locale? We have
> pg_get_encoding_from_locale() function that we can us
Peter Eisentraut writes:
> In plpgsql, if you write
> OPEN var BLAH
> you can an error message like this:
> ERROR: syntax error ...
> DETAIL: Expected "FOR", to open a reference cursor.
> But what is a "reference cursor"? Isn't this rather saying "... to open a
> cursor, a reference to whic
Peter Eisentraut writes:
> On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
>> We currently require that you set client_encoding correctly, or you get
>> garbage in psql and any other tool using libpq. How about setting
>> client_encoding automatically to match the client's locale? We
Pavel Golub writes:
> Is there any possibility that Postgres will have named transaction
> ever, like Firebird?
What in heck is a named transaction, and why should we care?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Wed, Jun 17, 2009 at 10:40 AM, Peter Eisentraut wrote:
> On Tuesday 16 June 2009 20:21:21 Tom Lane wrote:
>> As a concrete example of what I'm thinking about, I'd hope that PgAdmin
>> would be able to display a graphical summary of a plan tree, and then
>> pop up measurements associated with one
Tom Lane erote:
Peter Eisentraut writes:
Why don't we tell people to write a plpgsql loop for the schema.* case as
well?
Indeed, why not? This all seems much more like gilding the lily than
delivering useful new capability. The default-ACL stuff that Stephen
is working on seems far
Peter Eisentraut wrote:
I think you should design this with a bit wider scope. Instead of just "all
tables in this schema", think "all tables satisfying some condition". It has
been requested, for example, to be able to grant on all tables that match a
pattern.
Well, that's certainly possi
On Tuesday 16 June 2009 20:21:21 Tom Lane wrote:
> As a concrete example of what I'm thinking about, I'd hope that PgAdmin
> would be able to display a graphical summary of a plan tree, and then
> pop up measurements associated with one of the nodes when you
> right-click on that node. To do this,
* Petr Jelinek (pjmo...@pjmodos.net) wrote:
> It is context diff, at least I think so, I followed the instructions on
> wiki on how to make context patch from git repo.
err, sorry, tbh I just looked at the 'diff --git' line and didn't see
any '-c'.. Trying to do too much at one time, I'm afraid
Peter Eisentraut writes:
> Why don't we tell people to write a plpgsql loop for the schema.* case as
> well?
Indeed, why not? This all seems much more like gilding the lily than
delivering useful new capability. The default-ACL stuff that Stephen
is working on seems far more important in pract
On Wednesday 17 June 2009 17:15:04 Tom Lane wrote:
> Peter Eisentraut writes:
> > I think you should design this with a bit wider scope. Instead of just
> > "all tables in this schema", think "all tables satisfying some
> > condition". It has been requested, for example, to be able to grant on
>
* Petr Jelinek (pjmo...@pjmodos.net) wrote:
> Stephen Frost wrote:
>> I don't like the idea that a 'GRANT ALL' would actually change default
>> ACLs for a schema though. These are two separate and distinct things-
>> one is implementing a change to existing objects, the other is setting a
>> defau
Stephen Frost wrote:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
First big thing is that the patch should be a context diff. I would
It is context diff, at least I think so, I followed the instructions on
wiki on how to make context patch from git repo.
also recommend you put it u
Stephen Frost wrote:
I don't like the idea that a 'GRANT ALL' would actually change default
ACLs for a schema though. These are two separate and distinct things-
one is implementing a change to existing objects, the other is setting a
default for new objects. Mixing them would lead to confusion
On Tuesday 16 June 2009 22:51:37 Robert Haas wrote:
> I agree. I'm just not seeing the need for an *explicit*
> categorization contained within the data itself. For one thing, AIUI,
> that's the job of things like an XML Schema, which Andres Freund has
> already agreed to write, and I would expec
Petr,
* Petr Jelinek (pjmo...@pjmodos.net) wrote:
> So, here is the first version of the patch.
Neat, thanks! Some initial comments:
You should read through this:
http://wiki.postgresql.org/wiki/Submitting_a_Patch
First big thing is that the patch should be a context diff. I would
also recomm
On 06/17/2009 04:27 PM, Peter Eisentraut wrote:
On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
1. It didn't seem very wise to go with the approach of trying to do
EVERYTHING with attributes. If I did that, then I'd either get really
long lines that were not easily readable, or I'd have to
On Wed, Jun 17, 2009 at 10:27 AM, Peter Eisentraut wrote:
> On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
>> 1. It didn't seem very wise to go with the approach of trying to do
>> EVERYTHING with attributes. If I did that, then I'd either get really
>> long lines that were not easily readabl
On Tuesday 16 June 2009 16:22:27 Robert Haas wrote:
> 1. It didn't seem very wise to go with the approach of trying to do
> EVERYTHING with attributes. If I did that, then I'd either get really
> long lines that were not easily readable, or I'd have to write some
> kind of complicated line wrappin
Peter Eisentraut writes:
> I think you should design this with a bit wider scope. Instead of just "all
> tables in this schema", think "all tables satisfying some condition". It has
> been requested, for example, to be able to grant on all tables that match a
> pattern.
I'm against that. Fu
Peter,
* Peter Eisentraut (pete...@gmx.net) wrote:
> > Also since this patch introduces VIEWS as object with grantable
> > privileges, I added GRANT ON VIEW foo syntax which is more or less
> > synonymous to GRANT ON TABLE foo syntax. It felt weird to have GRANT ON
> > ALL VIEWS but not GRANT ON V
On Wednesday 17 June 2009 11:29:10 Petr Jelinek wrote:
> The patch allows "GRANT ON ALL TABLES/VIEWS/FUNCTIONS/SEQUENCES IN
> schemaname, schemaname2 TO username" and same thing for REVOKE.
> Words TABLES, VIEWS, FUNCTIONS and SEQUENCES were added as unreserved
> keywords. Unfortunately I was unabl
In plpgsql, if you write
OPEN var BLAH
you can an error message like this:
ERROR: syntax error ...
DETAIL: Expected "FOR", to open a reference cursor.
But what is a "reference cursor"? Isn't this rather saying "... to open a
cursor, a reference to which will be stored in your variable"? An
On Wednesday 17 June 2009 14:29:26 Heikki Linnakangas wrote:
> We currently require that you set client_encoding correctly, or you get
> garbage in psql and any other tool using libpq. How about setting
> client_encoding automatically to match the client's locale? We have
> pg_get_encoding_from_loc
Heikki Linnakangas wrote:
client_encoding defaults to server_encoding, which is correct in the
typical environment where the client and the server have identical
locale settings, which I believe is why we don't see more confused
users on mailing lists. However, a partner of ours was recentl
Jeremy Kerr wrote:
Hi all,
Speaking of which, what about some performance numbers?
OK, benchmarks done:
http://ozlabs.org/~jk/projects/db/data/postgres.bcTruelen/
Summary: small increase in performance (~1-2% on my machine), at about
1.5 standard deviations from the mean. Profiles show a
We currently require that you set client_encoding correctly, or you get
garbage in psql and any other tool using libpq. How about setting
client_encoding automatically to match the client's locale? We have
pg_get_encoding_from_locale() function that we can use to extract the
encoding from LC_CT
On Wed, Jun 17, 2009 at 3:26 PM, Jeremy Kerr wrote:
> Hurjeet,
>
> > http://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_G
> >it
>
> Awesome, thanks.
>
> I'm going to wait for a decision before reformatting and sending the
> diff.
>
You might want to submit the patch (if modified
Heikki Linnakangas wrote:
Jeremy Kerr wrote:
Speaking of which, what about some performance numbers?
OK, benchmarks done:
http://ozlabs.org/~jk/projects/db/data/postgres.bcTruelen/
Summary: small increase in performance (~1-2% on my machine), at about
1.5 standard deviations from the mean.
Hello, pgsql-hackers.
Is there any possibility that Postgres will have named transaction
ever, like Firebird?
Now for each transaction client should open separate connection. But
CONNECTION LIMIT option for database make this a little bit harder
--
With best wishes,
Pavel
Jeremy Kerr wrote:
Speaking of which, what about some performance numbers?
OK, benchmarks done:
http://ozlabs.org/~jk/projects/db/data/postgres.bcTruelen/
Summary: small increase in performance (~1-2% on my machine), at about
1.5 standard deviations from the mean. Profiles show a decent dro
On Wed, Jun 17, 2009 at 3:01 PM, Jeremy Kerr wrote:
> Will re-send the patch once I work out how to get git to create a
> context diff...
>
http://wiki.postgresql.org/wiki/Working_with_Git#Context_diffs_with_Git
--
Lets call it Postgres
EnterpriseDB http://www.enterprisedb.com
gurjeet[.
Hi all,
> Speaking of which, what about some performance numbers?
OK, benchmarks done:
http://ozlabs.org/~jk/projects/db/data/postgres.bcTruelen/
Summary: small increase in performance (~1-2% on my machine), at about
1.5 standard deviations from the mean. Profiles show a decent drop in
hits
So, here is the first version of the patch.
It includes functionality itself, simple regression test and also very
simple documentation.
The patch allows "GRANT ON ALL TABLES/VIEWS/FUNCTIONS/SEQUENCES IN
schemaname, schemaname2 TO username" and same thing for REVOKE.
Words TABLES, VIEWS, FUNCT
Hi,
On Wed, Jun 17, 2009 at 12:22 AM, Czichy, Thoralf (NSN -
FI/Helsinki) wrote:
> [STONITH is not always best strategy if failures can be declared as
> user-space software problem only, limit STONITH to HW/OS failures]
>
> The isolation of the failing Postgres instance does not require a
> STONIT
68 matches
Mail list logo
