On 15 November 2012 05:25, Hannu Krosing wrote:
> On 11/15/2012 09:48 AM, Craig Ringer wrote:
>>
>> If you want to prevent TRUNCATE, deny the privilege or add a trigger
>> that aborts the command.
>
> You can abort the transaction but not skip action as currently it is only
> possible to skip in R
On Fri, Nov 16, 2012 at 6:38 AM, Dimitri Fontaine wrote:
> Darren Duncan writes:
> > So, I'm partly proposing a specific narrow new feature, "TRUNCATE FOR
> EACH
> > ROW"
>
> Kevin has been proposing that we consider an alternative approach in
> some other cases that I think would work better for
On 11/16/2012 05:38 AM, Dimitri Fontaine wrote:
> Darren Duncan writes:
>> So, I'm partly proposing a specific narrow new feature, "TRUNCATE FOR EACH
>> ROW"
> Kevin has been proposing that we consider an alternative approach in
> some other cases that I think would work better for you, too. Namel
Dimitri Fontaine wrote:
Darren Duncan writes:
So, I'm partly proposing a specific narrow new feature, "TRUNCATE FOR EACH
ROW"
Kevin has been proposing that we consider an alternative approach in
some other cases that I think would work better for you, too. Namely, to
have access to OLD and NE
Darren Duncan writes:
> So, I'm partly proposing a specific narrow new feature, "TRUNCATE FOR EACH
> ROW"
Kevin has been proposing that we consider an alternative approach in
some other cases that I think would work better for you, too. Namely, to
have access to OLD and NEW in FOR EACH STATEMENT
On Thu, Nov 15, 2012 at 2:53 PM, Darren Duncan
wrote:
> I still think the syntax of TRUNCATE FOR EACH ROW would be useful, but if
no one agrees...
I'm compelled to disagree.
What was useful about TRUNCATE in the first place was that it quickly
operated against the entire table.
If you want to c
Craig Ringer wrote:
On 11/15/2012 06:25 PM, Hannu Krosing wrote:
On 11/15/2012 09:48 AM, Craig Ringer wrote:
If you want to prevent TRUNCATE, deny the privilege or add a trigger
that aborts the command.
You can abort the transaction but not skip action as currently it is only
possible to skip
On 11/15/2012 06:25 PM, Hannu Krosing wrote:
> On 11/15/2012 09:48 AM, Craig Ringer wrote:
>> If you want to prevent TRUNCATE, deny the privilege or add a trigger
>> that aborts the command.
> You can abort the transaction but not skip action as currently it is only
> possible to skip in ROW level
On 11/15/2012 09:48 AM, Craig Ringer wrote:
If you want to prevent TRUNCATE, deny the privilege or add a trigger
that aborts the command.
You can abort the transaction but not skip action as currently it is only
possible to skip in ROW level triggers.
So I'd modify this request to allow BEFORE
A row-level trigger for TRUNCATE does not really make sense, as it would
mean that TRUNCATE needs to scan each tuple of the table it needs to
interact with to fire its trigger, so it would more or less achieve the
same performance as a plain "DELETE FROM table;".
TRUNCATE is performant because it
On 11/15/2012 03:44 PM, Darren Duncan wrote:
> As they currently exist, triggers always fire based on certain SQL
> syntax used, rather than on the semantics of what is actually going on.
>
That's not quite right. COPY fires INSERT triggers, despite never using
an explicit INSERT statement. There
On Wed, Mar 28, 2012 at 01:55:06PM +0300, Anssi Kääriäinen wrote:
> It seems there is no way to get role members using psql. \du and \dg
> give you "this role is a member of" information, but no information
> about who have been granted the role.
>
> I would like to write a patch implementing this
On Sun, Nov 27, 2011 at 10:28 AM, Alexander Soudakov wrote:
> Hello.
>
> I finished developing www_fdw:
> https://github.com/cyga/www_fdw/
>
> It has docs/examples:
> https://github.com/cyga/www_fdw/wiki
>
> I haven't upload it to pgxn or pgfoundry yet.
>
> I want to ask for the following 2 things
Alexander Soudakov wrote:
> in addition to:
>> I want to ask for the following 2 things:
>> 1. testing from community;
>> 2. how can I add my extension to official fdw list:
>> http://wiki.postgresql.org/wiki/Foreign_data_wrappers
>> Is there any procedure for it?
>
> Can I have it included in
Also,
in addition to:
> I want to ask for the following 2 things:
> 1. testing from community;
> 2. how can I add my extension to official fdw list:
> http://wiki.postgresql.org/wiki/Foreign_data_wrappers
> Is there any procedure for it?
Can I have it included in 9.2?
On Sun, Nov 27, 2011 at 10:
Hello.
I finished developing www_fdw:
https://github.com/cyga/www_fdw/
It has docs/examples:
https://github.com/cyga/www_fdw/wiki
I haven't upload it to pgxn or pgfoundry yet.
I want to ask for the following 2 things:
1. testing from community;
2. how can I add my extension to official fdw list
On Sep29, 2011, at 16:43 , Dickson S. Guedes wrote:
> 2011/9/29 Florian Pflug :
>> You could use a hash table, allocated in the top-level memory context,
>> to store one authentication token per combination of server and local user.
>
> In fact I started something in this way, with ldap_fdw, stash
2011/9/29 Florian Pflug :
> You could use a hash table, allocated in the top-level memory context,
> to store one authentication token per combination of server and local user.
In fact I started something in this way, with ldap_fdw, stashing the
connection away using memory context and something u
On Sep29, 2011, at 14:45 , Dickson S. Guedes wrote:
> I'm working on a google_contacts_fdw to google contacts api [1] but
> stopped in the authentication design. As you can see in [2], for
> google api, you should get an authorization token and store the "Auth"
> value to use latter on the same "se
2011/9/28 Florian Pflug :
> On Sep28, 2011, at 15:32 , Alexander Soudakov wrote:
>> Here you can find www_fdw feature documentation:
>> http://wiki.postgresql.org/wiki/WWW_FDW
>
> Certainly looks useful (as a third-party extension, as others have already
> pointed out)
+1.
> What I didn't quite
On Thu, Sep 29, 2011 at 1:20 AM, Kevin Grittner
wrote:
> Florian Pflug wrote:
>> On Sep28, 2011, at 15:32 , Alexander Soudakov wrote:
>>> Here you can find www_fdw feature documentation:
>>> http://wiki.postgresql.org/wiki/WWW_FDW
>>
>> Certainly looks useful (as a third-party extension, as other
Florian Pflug wrote:
> On Sep28, 2011, at 15:32 , Alexander Soudakov wrote:
>> Here you can find www_fdw feature documentation:
>> http://wiki.postgresql.org/wiki/WWW_FDW
>
> Certainly looks useful (as a third-party extension, as others have
> already pointed out)
Our programmers agree that it
On Sep28, 2011, at 15:32 , Alexander Soudakov wrote:
> Here you can find www_fdw feature documentation:
> http://wiki.postgresql.org/wiki/WWW_FDW
Certainly looks useful (as a third-party extension, as others have already
pointed out)
What I didn't quite understand is how one would pass (dynamic)
Guys,
I suggest Alexander to announce his project just to let all us know and
avoid duplicate work. I hope it's a good starter project for Alexander !
I agree with Andrew, it's also should be posted to -general.
It's clear it should be an extension !
Oleg
On Wed, 28 Sep 2011, Tom Lane wrote:
Andrew Dunstan writes:
> Why should this be a core feature, as the subject suggests? It could
> just be an extension, like other FDWs, no?
In fact it had *better* be an extension, not core, because anything that
allows the server to go out and touch the web is going to be a security
hazard in so
On 09/28/2011 11:41 AM, Alexander Soudakov wrote:
On Wed, Sep 28, 2011 at 7:17 PM, David Fetter wrote:
On Wed, Sep 28, 2011 at 05:32:37PM +0400, Alexander Soudakov wrote:
Greetings postgres hackers!
Here you can find www_fdw feature documentation:
http://wiki.postgresql.org/wiki/WWW_FDW
Lo
On Wed, Sep 28, 2011 at 7:17 PM, David Fetter wrote:
> On Wed, Sep 28, 2011 at 05:32:37PM +0400, Alexander Soudakov wrote:
>> Greetings postgres hackers!
>>
>> Here you can find www_fdw feature documentation:
>> http://wiki.postgresql.org/wiki/WWW_FDW
>>
>> Looking forward for your feedback.
>
> D
On 09/28/2011 09:32 AM, Alexander Soudakov wrote:
Greetings postgres hackers!
Here you can find www_fdw feature documentation:
http://wiki.postgresql.org/wiki/WWW_FDW
Looking forward for your feedback.
Why should this be a core feature, as the subject suggests? It could
just be an extensi
On Wed, Sep 28, 2011 at 05:32:37PM +0400, Alexander Soudakov wrote:
> Greetings postgres hackers!
>
> Here you can find www_fdw feature documentation:
> http://wiki.postgresql.org/wiki/WWW_FDW
>
> Looking forward for your feedback.
Do you have some libraries you plan to base this on, or will you
not a problem because
starting/stopping the database/application is infrequent once the system is
in steady operation." -- this may sound abrupt, though.
Regards,
MauMau
- Original Message -
From: "Dave Page"
To: "Tom Lane"
Cc: "MauMau"
On Tue, May 10, 2011 at 11:55 PM, Tom Lane wrote:
> "MauMau" writes:
>>> "MauMau" writes:
I've encountered one problem on Windows. I need to support running all of
my
products on one host simultaneously. Plus, I need to log messages in
syslog/event log. On Linux, I can distin
"MauMau" writes:
>> "MauMau" writes:
>>> I've encountered one problem on Windows. I need to support running all of
>>> my
>>> products on one host simultaneously. Plus, I need to log messages in
>>> syslog/event log. On Linux, I can distinguish the messages of one product
>>> and those of other
From: "Tom Lane"
"MauMau" writes:
I've encountered one problem on Windows. I need to support running all of
my
products on one host simultaneously. Plus, I need to log messages in
syslog/event log. On Linux, I can distinguish the messages of one product
and those of other products by setting
Added to TODO list:
Allow multiple Postgres clusters running on the same machine to
distinguish themselves in the event log
http://archives.postgresql.org/pgsql-hackers/2011-03/msg01297.php
I'm sorry that I've mistakenly sent an empty mail. This is the intended
mail.
"Andrew Dunstan" wrote in message
news:4d889879.3080...@dunslane.net...
On 03/22/2011 08:22 AM, MauMau wrote:
I would appreciate your opinions and advice. I'll try making the patch
while I'm waiting for response.
On 03/22/2011 11:35 AM, MauMau wrote:
> I'm sorry that I've mistakenly sent an empty mail. This is the
> intended mail.
>
> "Andrew Dunstan" wrote in message
> news:4d889879.3080...@dunslane.net...
>>
>> On 03/22/2011 08:22 AM, MauMau wrote:
>>> I would appreciate your opinions and advice. I'll
I'm sorry that I've mistakenly sent an empty mail. This is the intended
mail.
"Andrew Dunstan" wrote in message
news:4d889879.3080...@dunslane.net...
On 03/22/2011 08:22 AM, MauMau wrote:
I would appreciate your opinions and advice. I'll try making the patch
while I'm waiting for response.
"MauMau" writes:
> I've encountered one problem on Windows. I need to support running all of my
> products on one host simultaneously. Plus, I need to log messages in
> syslog/event log. On Linux, I can distinguish the messages of one product
> and those of other products by setting syslog_iden
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/22/2011 08:22 AM, MauMau wrote:
> Hello,
>
> I have several software products which use PostgreSQL as a data
> repository and embed the same PostgreSQL binaries. Currently, those
> software support Linux. I'm trying to port them to Windows.
>
> I've encountered one problem on Windows. I nee
Added to TODO:
o Allow COPY to output from views
---
Andrew Dunstan wrote:
>
>
> Rod Taylor wrote:
>
> >On Wed, 2005-09-21 at 15:25 -0700, Trent Shipley wrote:
> >
> >
> >>
> >>Wouldn't you also need a CREATE T
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> So we could refute this argument by just not making the permission check for
>> CREATE TEMP VIEW.
> This is the first time I've ever heard of CREATE TEMP VIEW. What's the point
> of it since you can always directly do
Tom Lane <[EMAIL PROTECTED]> writes:
> So we could refute this argument by just not making the permission check for
> CREATE TEMP VIEW.
This is the first time I've ever heard of CREATE TEMP VIEW. What's the point
of it since you can always directly do:
SELECT * FROM (...)
?
--
greg
-
On K, 2005-09-21 at 20:34 -0400, Rod Taylor wrote:
> Sure. But if you are using STDOUT then why does this need to be a server
> side item at all?
>
> You either have code issuing the commands and collecting the results
> making a standard select just as fast or you are using psql which
> already h
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Rod Taylor wrote:
>> Writing a file on the server requires significant privilege, including
>> access to the server itself so you can retrieve the results.
> But we also do COPY to STDOUT which requires no special privileges on
> the server.
Currently
Rod Taylor wrote:
You either have code issuing the commands and collecting the results
making a standard select just as fast or you are using psql which
already has multiple display types for SELECT data, including XML
output, but another could easily be added for CSV style output.
We ha
On Wed, 2005-09-21 at 19:55 -0400, Andrew Dunstan wrote:
>
> Rod Taylor wrote:
>
> >On Wed, 2005-09-21 at 15:25 -0700, Trent Shipley wrote:
> >
> >
> >>
> >>Wouldn't you also need a CREATE TEMP TABLE privilege but the
> >>COPY TO file USING select_statement
> >>would only need select. (In oth
Rod Taylor wrote:
On Wed, 2005-09-21 at 15:25 -0700, Trent Shipley wrote:
Wouldn't you also need a CREATE TEMP TABLE privilege but the
COPY TO file USING select_statement
would only need select. (In other words using a temp table would not seem to
be as secure nor as general as the req
On Wed, 2005-09-21 at 15:25 -0700, Trent Shipley wrote:
> On Wednesday 2005-09-21 07:01, Hans-Jürgen Schönig wrote:
> > Rod Taylor wrote:
> > >>the problem is: COPY can write data returned by a SELECT statement to a
> > >>file. our idea is to implement precisely that.
> > >>
> > >>example:
> > >>
>
On Wednesday 2005-09-21 07:01, Hans-Jürgen Schönig wrote:
> Rod Taylor wrote:
> >>the problem is: COPY can write data returned by a SELECT statement to a
> >>file. our idea is to implement precisely that.
> >>
> >>example:
> >>
> >>COPY TO file_name USING some_select_statement;
> >
> > I have run i
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> COPY TO file_name USING some_select_statement;
I think this has been discussed before, check the archives.
> to implement the desired feature we just had to add some SPI code to the
> scenery (SPI will also return HeapTuples
Rod Taylor wrote:
the problem is: COPY can write data returned by a SELECT statement to a
file. our idea is to implement precisely that.
example:
COPY TO file_name USING some_select_statement;
I have run into plenty of cases where I wanted to dump part of a
structure and this could be used
> the problem is: COPY can write data returned by a SELECT statement to a
> file. our idea is to implement precisely that.
>
> example:
>
> COPY TO file_name USING some_select_statement;
I have run into plenty of cases where I wanted to dump part of a
structure and this could be used for that,
53 matches
Mail list logo
