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
I have a feature request, which at one level should require little code change,
but at another level may require more.
Since Postgres 9.3 is going to be doing some significant feature additions for
triggers, I'd like to see some more.
As they currently exist, triggers always fire based on cer
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
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 feature. Some questions:
- Is this wanted?
- Should there be a new f
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
Greetings postgres hackers!
Here you can find www_fdw feature documentation:
http://wiki.postgresql.org/wiki/WWW_FDW
Looking forward for your feedback.
--
Alexander Soudakov
Developer Programmer
email: cyga...@gmail.com
skype: asudakov
--
Sent via pgsql-hackers mailing list (pgsql-hackers@pos
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
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 need to support running all of my
products on one
On Thursday 2005-09-22 13:16, Andrew Dunstan wrote:
> Jim C. Nasby wrote:
> >While I'm all for COPY from views, I think I'd rather have the syntactic
> >warts than code warts. ISTM that
> >
> >CREATE TEMP VIEW some_name AS SELECT * FROM table WHERE ...;
> >COPY some_name TO stdout;
> >
> >is much u
AgentM wrote:
> >
> > While I'm all for COPY from views, I think I'd rather have the
> > syntactic
> > warts than code warts. ISTM that
> >
> > CREATE TEMP VIEW some_name AS SELECT * FROM table WHERE ...;
> > COPY some_name TO stdout;
> >
> > is much uglier than
> >
> > COPY SELECT * FROM table W
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
So why not do what everyone is agreed on now?
I wasn't agreed on it ;-)
The primary objection I've got is that I think this will be a very
considerable increment of work for exactly zero increment in
functionality, compared
> From: Andrew Dunstan [mailto:[EMAIL PROTECTED]
> Also, as nifty as this might be, we should also be prepared
> for people
> to complain that it runs a lot slower than vanilla COPY, because it
> surely will.
At which point we point out to them that it's also much faster than any of the
other
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> So why not do what everyone is agreed on now?
I wasn't agreed on it ;-)
The primary objection I've got is that I think this will be a very
considerable increment of work for exactly zero increment in
functionality, compared to being able to copy from a
Jim C. Nasby wrote:
While I'm all for COPY from views, I think I'd rather have the syntactic
warts than code warts. ISTM that
CREATE TEMP VIEW some_name AS SELECT * FROM table WHERE ...;
COPY some_name TO stdout;
is much uglier than
COPY SELECT * FROM table WHERE ... TO stdout;
They are
On N, 2005-09-22 at 21:34 +0200, Hans-Juergen Schoenig wrote:
> absolutely - the main advantage of the syntax tweak is that you can
> add parameters more easily.
Perhaps "COPY from SQL FUNCTIONS" is what wou need ?
Or should we piggypack on (future) work needed for hierarchical queries
and hav
While I'm all for COPY from views, I think I'd rather have the
syntactic
warts than code warts. ISTM that
CREATE TEMP VIEW some_name AS SELECT * FROM table WHERE ...;
COPY some_name TO stdout;
is much uglier than
COPY SELECT * FROM table WHERE ... TO stdout;
Or, you could just allow subqu
absolutely - the main advantage of the syntax tweak is that you can
add parameters more easily.
best regards,
hans
On 22 Sep 2005, at 21:25, Jim C. Nasby wrote:
On Wed, Sep 21, 2005 at 11:31:42AM -0400, Tom Lane wrote:
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTE
On Wed, Sep 21, 2005 at 11:31:42AM -0400, Tom Lane wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> > Paolo Magnoli wrote:
> >> Can't you just use a view?
>
> > no because a new is not a heap ...
>
> I think Paolo's idea is much better than munging the syntax of COP
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 Wed, 2005-09-21 at 11:31 -0400, Tom Lane wrote:
> =?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> > Paolo Magnoli wrote:
> >> Can't you just use a view?
>
> > no because a new is not a heap ...
>
> I think Paolo's idea is much better than munging the syntax of COPY,
> th
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
Paolo Magnoli
Cc: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Subject: Re: R: [HACKERS] feature proposal ...
no because a new is not a heap ...
em=# create view x as select * from pg_class;
CREATE VIEW
em=# copy x to '/tmp/x';
ERROR: cannot copy from view "x&qu
to di Hans-Jürgen
Schönig
Inviato: mercoledì 21 settembre 2005 15.30
A: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Oggetto: [HACKERS] feature proposal ...
hackers,
currently we have to hack tons of export scripts for various customers.
the problem is: if tables can be exported straight forwa
Joshua D. Drake wrote:
Hans-Jürgen Schönig wrote:
no because a new is not a heap ...
Why not use a function with a temporary table?
That way you can pass a table parameter that
is the temporary table with a select statement
that you can populate the temp table with.
Sincerely,
Joshua D. D
=?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
=?ISO-8859-1?Q?Hans-J=FCrgen_Sch=F6nig?= <[EMAIL PROTECTED]> writes:
> Paolo Magnoli wrote:
>> Can't you just use a view?
> no because a new is not a heap ...
I think Paolo's idea is much better than munging the syntax of COPY,
though. Fixing COPY so that you *could* copy from a view would provi
originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] conto di Hans-Jürgen
Schönig
Inviato: mercoledì 21 settembre 2005 15.30
A: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Oggetto: [HACKERS] feature proposal ...
hackers,
currently we have to hack tons of export scripts for various cust
Can't you just use a view?
-Messaggio originale-
Da: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] conto di Hans-Jürgen
Schönig
Inviato: mercoledì 21 settembre 2005 15.30
A: pgsql-hackers@postgresql.org; [EMAIL PROTECTED]
Oggetto: [HACKERS] feature proposal ...
hackers,
currently we
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,
hackers,
currently we have to hack tons of export scripts for various customers.
the problem is: if tables can be exported straight forward COPY will
give you all you need but when data has to be transformed while
exporting things start becoming a bit more complex. usually people want
to have
75 matches
Mail list logo
