Hi Michael,
On 2013-02-07 16:45:57 +0900, Michael Paquier wrote:
> Please find attached a patch fixing 3 of the 4 problems reported before
> (the patch does not contain docs).
Cool!
> 1) Removal of the quadratic dependency with list_append_unique_oid
> 2) Minimization of the wait phase for paren
2013/2/7 Andres Freund :
> On 2013-02-06 13:25:31 -0800, Josh Berkus wrote:
>> Mind you, when I explained our current CF review workflow for the SF
>> ReviewFest last year, the attendees thought I was insane. It's kept me
>> from doing more reviewfests. Our current workflow and tooling is
>> defini
On 2013-02-06 13:25:31 -0800, Josh Berkus wrote:
> Mind you, when I explained our current CF review workflow for the SF
> ReviewFest last year, the attendees thought I was insane. It's kept me
> from doing more reviewfests. Our current workflow and tooling is
> definitely a serious obstacle to gett
On 7 February 2013 08:07, Josh Berkus wrote:
> The existing Gerrit community would be keen to have the PostgreSQL
> project as a major user, though, and would theoretically help with
> modification needs. Current major users are OpenStack, Mediawiki,
> LibreOffice and QT.
Do we actually have any
On Wed, Feb 6, 2013 at 3:00 PM, Joshua D. Drake wrote:
>
> On 02/06/2013 01:53 PM, Tom Lane wrote:
>
>> ... if it's going to try to coerce us out of our email-centric habits,
>> then I for one am very much against it. To me, the problems with the
>> existing CF app are precisely that it's not wel
Jeff Janes writes:
> While stress testing Pavan's 2nd pass vacuum visibility patch, I realized
> that vacuum/visibility was busted. But it wasn't his patch that busted it.
> As far as I can tell, the bad commit was in the
> range 692079e5dcb331..168d3157032879
> Since a run takes 12 to 24 hours
While stress testing Pavan's 2nd pass vacuum visibility patch, I realized
that vacuum/visibility was busted. But it wasn't his patch that busted it.
As far as I can tell, the bad commit was in the
range 692079e5dcb331..168d3157032879
Since a run takes 12 to 24 hours, it will take a while to refi
On Wed, Feb 6, 2013 at 11:42 PM, Merlin Moncure wrote:
> >> *) hacking pg_operator (carefully look up and change oprname for the
> >> specific hstore operator)
> >
> >
> > bad solution. Why not just provide an additional operator?
> >
> >CREATE OPERATOR ~ (
> > LEFTARG = hstore,
> >
tl;dr
Scala/JRuby/Clojure (any JVM-based language) + Postgres + hstore =
awesome... why not just add a few lines to hstore--1.2.sql and make sure
that all operators are available and indexable?
hi Andrew, hi merlin,
use the existing "exist()" function
EXIST() can't use hstore's GiST or GI
On 7.2.2013 00:40, Tom Lane wrote:
> Jeff Janes writes:
>> On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra wrote:
>>> U, what you mean by "catalog bump"?
>
>> There is a catalog number in src/include/catalog/catversion.h, which
>> when changed forces one to redo initdb.
>
>> Formally I guess i
I wrote:
> Tomas Vondra writes:
>> I've managed to further simplify the test-case, and I've verified that
>> it's reproducible on current 9.2 and 9.3 branches.
> It seems that
> (1) gistfindgroup decides that SimpleTestString is "equiv" to something.
> It's not too clear what; for sure there is
Jeff Janes writes:
> On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra wrote:
>> U, what you mean by "catalog bump"?
> There is a catalog number in src/include/catalog/catversion.h, which
> when changed forces one to redo initdb.
> Formally I guess it is only for system catalog changes, but I th
On Tue, Feb 5, 2013 at 2:31 PM, Tomas Vondra wrote:
> On 5.2.2013 19:23, Jeff Janes wrote:
>
>> If I shutdown the server and blow away the stats with "rm
>> data/pg_stat/*", it recovers gracefully when I start it back up. If a
>> do "rm -r data/pg_stat" then it has problems the next time I shut i
On Wed, Feb 06, 2013 at 10:17:09PM +0100, Magnus Hagander wrote:
> I just took a quick look at their system, and when they start talking
> about requirements in the 100's of Gb of RAM, 24 core machines and
> SSD, I get scared :) But that's to "scale" it - doesn't mention when
> you need to do anyth
On 02/06/2013 01:53 PM, Tom Lane wrote:
... if it's going to try to coerce us out of our email-centric habits,
then I for one am very much against it. To me, the problems with the
existing CF app are precisely that it's not well enough integrated with
the email discussions. The way to fix tha
Magnus Hagander writes:
> On Wed, Feb 6, 2013 at 10:07 PM, Josh Berkus wrote:
>> As an occasional CommitFest manager, I'm keenly aware of the makeshift
>> nature of the CommitFest app. If we want to go on using it -- and if we
>> want to attract additional reviewers -- we need to improve it
>> s
On 06/02/2013 22:25, Josh Berkus wrote:
Mind you, when I explained our current CF review workflow for the SF
ReviewFest last year, the attendees thought I was insane. It's kept me
from doing more reviewfests. Our current workflow and tooling is
definitely a serious obstacle to gettng more reviewe
> This is probably not something we should discuss right now - it's
> better discussed when we're not right inthe middle of a commitfest,
> no?
Well, *if* we were to change tooling, the time to do it would be during
beta. Hence, bringing it up now.
> We have no ad-hoc PHP, but I'm assume you're
On Wed, Feb 6, 2013 at 10:07 PM, Josh Berkus wrote:
> Hackers,
>
> As an occasional CommitFest manager, I'm keenly aware of the makeshift
> nature of the CommitFest app. If we want to go on using it -- and if we
> want to attract additional reviewers -- we need to improve it
> substantially. Wha
Hackers,
As an occasional CommitFest manager, I'm keenly aware of the makeshift
nature of the CommitFest app. If we want to go on using it -- and if we
want to attract additional reviewers -- we need to improve it
substantially. What Robert built for us was supposed to be a second
draft, not a f
On Wed, Feb 6, 2013 at 1:06 PM, Simon Riggs wrote:
> On 6 February 2013 17:43, Robert Haas wrote:
>> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs wrote:
>>> On 4 February 2013 19:53, Robert Haas wrote:
This seems pretty close to an accusation of bad faith, which I don't
believe to be p
On Wed, Feb 6, 2013 at 1:47 PM, Heikki Linnakangas
wrote:
> On 06.02.2013 20:02, Robert Haas wrote:
>>
>> On Wed, Feb 6, 2013 at 12:43 PM, Simon Riggs
>> wrote:
2. I don't like demoting the trigger file method to a second class
citizen. I think we should make all functionality avail
On Wed, Feb 6, 2013 at 12:00 PM, Andrew Dunstan wrote:
>
> On 02/06/2013 12:34 PM, Merlin Moncure wrote:
>>
>>
>> The point is that Postgres should not introduce language constraints
>> because of broken driver technology.
>
>
> +1
>
>
>> To move forward in your
>> particular case, consider:
>> *)
On 02/06/2013 02:24 PM, Merlin Moncure wrote:
On Wed, Feb 6, 2013 at 1:08 PM, David E. Wheeler wrote:
Hackers,
While playing with Andrew’s JSON enhancements, I noticed this:
david=# select * From json_each_as_text('{"baz": null}'::json);
key | value
-+---
baz |
On Wed, Feb 6, 2013 at 1:08 PM, David E. Wheeler wrote:
> Hackers,
>
> While playing with Andrew’s JSON enhancements, I noticed this:
>
> david=# select * From json_each_as_text('{"baz": null}'::json);
> key | value
> -+---
> baz | null
>
> It is returning 'null'::text th
On 2013-02-06 15:51:15 -0300, Alvaro Herrera wrote:
> Okay, here's an attempt at doing it that way. Notably this creates
> libpgcommon, a static library, to be used by both frontend and backend.
> There's only a frontend file now (fe_memutils.c); the backend side of it
> is empty. I verified tha
Hackers,
While playing with Andrew’s JSON enhancements, I noticed this:
david=# select * From json_each_as_text('{"baz": null}'::json);
key | value
-+---
baz | null
It is returning 'null'::text there, not NULL::text. I had expected the latter,
because otherwise it's n
Tom Lane escribió:
> Simon Riggs writes:
> > On 6 February 2013 14:38, Alvaro Herrera wrote:
> >> Yeah, I am doing this right now and the "shared" name doesn't seem so
> >> good. "libpgframework" sounds decent. So since libpgport comes from
> >> src/port, are we okay with src/framework and src/
On 06.02.2013 20:02, Robert Haas wrote:
On Wed, Feb 6, 2013 at 12:43 PM, Simon Riggs wrote:
2. I don't like demoting the trigger file method to a second class
citizen. I think we should make all functionality available through both
methods. If there was a good reason for deprecating the trigger
On 6 February 2013 17:43, Robert Haas wrote:
> On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs wrote:
>> On 4 February 2013 19:53, Robert Haas wrote:
>>> This seems pretty close to an accusation of bad faith, which I don't
>>> believe to be present.
>>
>> Robert, this is not an accusation of bad fai
On Wed, Feb 6, 2013 at 12:43 PM, Simon Riggs wrote:
>> 2. I don't like demoting the trigger file method to a second class
>> citizen. I think we should make all functionality available through both
>> methods. If there was a good reason for deprecating the trigger file
>> method, I could live with
On 02/06/2013 12:34 PM, Merlin Moncure wrote:
The point is that Postgres should not introduce language constraints
because of broken driver technology.
+1
To move forward in your
particular case, consider:
*) switching to 'hstore defined()' function:
good solution - but just use the exist
Apologies for posting on multiple lists, surely will take care of this next
time.
Yup adding user=username resolved this. Thanks to 'Laurenz Albe' and you
too.
Regards - Dev
On Wed, Feb 6, 2013 at 7:12 PM, Andrew Dunstan wrote:
>
> On 02/06/2013 08:09 AM, Dev Kumkar wrote:
>
>> Hello Everyone,
On 02/06/2013 09:43 AM, Simon Riggs wrote:
4. I think fast promotion should be the default. Why not? There are
cases where you want the promotion to happen ASAP, and there are cases
where you don't care. But there are no scenarios where you want
promotion to be slow,
Not true. Slow means safe
On 6 February 2013 16:36, Heikki Linnakangas wrote:
> On 31.01.2013 21:33, Simon Riggs wrote:
>>
>> If anyone really wants me to revert, pls start new hackers thread to
>> discuss, or comment on changes.
>
>
> Yes, I still think this needs fixing or reverting. Let me reiterate my
> my complaints:
On Mon, Feb 4, 2013 at 3:32 PM, Simon Riggs wrote:
> On 4 February 2013 19:53, Robert Haas wrote:
>> This seems pretty close to an accusation of bad faith, which I don't
>> believe to be present.
>
> Robert, this is not an accusation of bad faith, just an observation
> that we can move forwards m
On Wed, Feb 6, 2013 at 11:20 AM, Seamus Abshere wrote:
> merlin,
>
> Yes, you're correct, my phrasing was bad: all I meant was that it was a
> conflict, not a bug in Postgres or hstore.
>
> I personally don't know of any way around the conflict except changing JDBC
> or hstore, and I don't think J
On Wed, Feb 6, 2013 at 12:28 PM, Christopher Browne wrote:
> On Wed, Feb 6, 2013 at 12:05 PM, Robert Haas wrote:
>> On Wed, Feb 6, 2013 at 9:44 AM, Dimitri Fontaine
>> wrote:
>>> Robert Haas writes:
> I disagree with that. I don't see why the enclosing event trigger
> shouldn't be awar
On Wed, Feb 6, 2013 at 11:30 AM, Dimitri Fontaine
wrote:
> Alvaro Herrera writes:
>> Dimitri Fontaine escribió:
>>> Tom Lane writes:
>>> > I might be forgetting something, but doesn't dependency.c work by first
>>> > constructing a list of all the objects it's going to drop, and only then
>>> >
On Wed, Feb 6, 2013 at 12:05 PM, Robert Haas wrote:
> On Wed, Feb 6, 2013 at 9:44 AM, Dimitri Fontaine
> wrote:
>> Robert Haas writes:
I disagree with that. I don't see why the enclosing event trigger
shouldn't be aware of all the objects dropped by the command that just
ran to c
On Wed, Feb 6, 2013 at 11:04 AM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Alvaro Herrera writes:
>>> I thought there was the idea that the list of objects to drop was to be
>>> acquired before actually doing the deletion; so that the trigger
>>> function could, for instance, get the name of
On Wed, Feb 6, 2013 at 11:36 AM, Fujii Masao wrote:
> On Thu, Feb 7, 2013 at 1:15 AM, Phil Sorber wrote:
>> On Wed, Feb 6, 2013 at 11:11 AM, Fujii Masao wrote:
>>> On Thu, Feb 7, 2013 at 12:05 AM, Phil Sorber wrote:
On Tue, Feb 5, 2013 at 12:44 PM, Phil Sorber wrote:
> On Tue, Feb 5,
On Wed, Feb 6, 2013 at 9:44 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>>> I disagree with that. I don't see why the enclosing event trigger
>>> shouldn't be aware of all the objects dropped by the command that just
>>> ran to completion, *including* the effects of any event trigger fired
On Tue, Feb 5, 2013 at 11:29 AM, Seamus Abshere wrote:
> hi,
>
> As reported in BUG #7715 [1], hstore's use of ? as an operator conflicts
> with JDBC's bind variables.
>
> I think we could just alias ? to ~ and tell JDBC users to use that instead.
> [2]
This is not a bug with postgres, but with j
On 31.01.2013 21:33, Simon Riggs wrote:
If anyone really wants me to revert, pls start new hackers thread to
discuss, or comment on changes.
Yes, I still think this needs fixing or reverting. Let me reiterate my
my complaints:
1. I don't like the check in ReadCheckPointRecord() that the WAL
co
On Thu, Feb 7, 2013 at 1:15 AM, Phil Sorber wrote:
> On Wed, Feb 6, 2013 at 11:11 AM, Fujii Masao wrote:
>> On Thu, Feb 7, 2013 at 12:05 AM, Phil Sorber wrote:
>>> On Tue, Feb 5, 2013 at 12:44 PM, Phil Sorber wrote:
On Tue, Feb 5, 2013 at 9:08 AM, Phil Sorber wrote:
> On Tue, Feb 5, 2
Tom Lane writes:
> Well, a list of object OIDs is of exactly zero use once the command
> has been carried out. So I don't think that that represents a useful
> or even very testable feature on its own, if there's no provision to
> fire user code while the OIDs are still in the catalogs.
For the
On Wed, Feb 6, 2013 at 11:22 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Feb 5, 2013 at 12:18 AM, Phil Sorber wrote:
>>> On Mon, Feb 4, 2013 at 10:52 PM, Tom Lane wrote:
I don't believe that callers should be trying to free() the result.
Whether it's been strdup'd or not is n
Dimitri Fontaine writes:
> Tom Lane writes:
>> I might be forgetting something, but doesn't dependency.c work by first
>> constructing a list of all the objects it's going to drop, and only then
>> dropping them? Could we inject a "pre deletion" event trigger call at
>> the point where the list
Alvaro Herrera writes:
> Dimitri Fontaine escribió:
>> Tom Lane writes:
>> > I might be forgetting something, but doesn't dependency.c work by first
>> > constructing a list of all the objects it's going to drop, and only then
>> > dropping them? Could we inject a "pre deletion" event trigger ca
Dne 06.02.2013 16:53, Alvaro Herrera napsal:
Tom Lane escribió:
Pavel Stehule writes:
>> Nice. Another interesting numbers would be device utilization,
average
>> I/O speed and required space (which should be ~2x the pgstat.stat
size
>> without the patch).
> this point is important - with l
Robert Haas writes:
> On Tue, Feb 5, 2013 at 12:18 AM, Phil Sorber wrote:
>> On Mon, Feb 4, 2013 at 10:52 PM, Tom Lane wrote:
>>> I don't believe that callers should be trying to free() the result.
>>> Whether it's been strdup'd or not is not any of their business.
>> Is that just because of th
Dimitri Fontaine escribió:
> Tom Lane writes:
> > I might be forgetting something, but doesn't dependency.c work by first
> > constructing a list of all the objects it's going to drop, and only then
> > dropping them? Could we inject a "pre deletion" event trigger call at
> > the point where the
Simon Riggs writes:
> On 6 February 2013 14:38, Alvaro Herrera wrote:
>> Yeah, I am doing this right now and the "shared" name doesn't seem so
>> good. "libpgframework" sounds decent. So since libpgport comes from
>> src/port, are we okay with src/framework and src/include/framework?
> "common
Tom Lane writes:
> I might be forgetting something, but doesn't dependency.c work by first
> constructing a list of all the objects it's going to drop, and only then
> dropping them? Could we inject a "pre deletion" event trigger call at
> the point where the list is completed?
What happens if t
On Wed, Feb 6, 2013 at 11:11 AM, Fujii Masao wrote:
> On Thu, Feb 7, 2013 at 12:05 AM, Phil Sorber wrote:
>> On Tue, Feb 5, 2013 at 12:44 PM, Phil Sorber wrote:
>>> On Tue, Feb 5, 2013 at 9:08 AM, Phil Sorber wrote:
On Tue, Feb 5, 2013 at 9:06 AM, Alvaro Herrera
wrote:
> Phil So
On Thu, Feb 7, 2013 at 12:05 AM, Phil Sorber wrote:
> On Tue, Feb 5, 2013 at 12:44 PM, Phil Sorber wrote:
>> On Tue, Feb 5, 2013 at 9:08 AM, Phil Sorber wrote:
>>> On Tue, Feb 5, 2013 at 9:06 AM, Alvaro Herrera
>>> wrote:
Phil Sorber escribió:
> On Tue, Feb 5, 2013 at 6:41 AM, Robert
Dimitri Fontaine writes:
> Alvaro Herrera writes:
>> I thought there was the idea that the list of objects to drop was to be
>> acquired before actually doing the deletion; so that the trigger
>> function could, for instance, get the name of the table being dropped.
> Tom and Robert have been ri
2013/2/6 Alvaro Herrera :
> Tom Lane escribió:
>> Pavel Stehule writes:
>> >> Nice. Another interesting numbers would be device utilization, average
>> >> I/O speed and required space (which should be ~2x the pgstat.stat size
>> >> without the patch).
>>
>> > this point is important - with large w
Tom Lane escribió:
> Pavel Stehule writes:
> >> Nice. Another interesting numbers would be device utilization, average
> >> I/O speed and required space (which should be ~2x the pgstat.stat size
> >> without the patch).
>
> > this point is important - with large warehouse with lot of databases
>
Pavel Stehule writes:
>> Nice. Another interesting numbers would be device utilization, average
>> I/O speed and required space (which should be ~2x the pgstat.stat size
>> without the patch).
> this point is important - with large warehouse with lot of databases
> and tables you have move stat f
On Tue, Feb 5, 2013 at 12:44 PM, Phil Sorber wrote:
> On Tue, Feb 5, 2013 at 9:08 AM, Phil Sorber wrote:
>> On Tue, Feb 5, 2013 at 9:06 AM, Alvaro Herrera
>> wrote:
>>> Phil Sorber escribió:
On Tue, Feb 5, 2013 at 6:41 AM, Robert Haas wrote:
> On Sat, Feb 2, 2013 at 9:55 PM, Phil Sor
On Wed, Feb 6, 2013 at 9:59 AM, Simon Riggs wrote:
> On 6 February 2013 14:38, Alvaro Herrera wrote:
>> Robert Haas escribió:
>>> On Mon, Feb 4, 2013 at 5:50 PM, Alvaro Herrera
>>> wrote:
>>
>>> > I propose to have a new subdirectory src/include/shared, and two
>>> > header files:
>>
>>> > The
On 6 February 2013 14:38, Alvaro Herrera wrote:
> Robert Haas escribió:
>> On Mon, Feb 4, 2013 at 5:50 PM, Alvaro Herrera
>> wrote:
>
>> > I propose to have a new subdirectory src/include/shared, and two
>> > header files:
>
>> > The frontend (pg_malloc) function definitions would live somewhere
Robert Haas writes:
>> I disagree with that. I don't see why the enclosing event trigger
>> shouldn't be aware of all the objects dropped by the command that just
>> ran to completion, *including* the effects of any event trigger fired
>> recursively or not.
>
> Well, that could result in some DRO
On Tue, Feb 5, 2013 at 12:18 AM, Phil Sorber wrote:
> On Mon, Feb 4, 2013 at 10:52 PM, Tom Lane wrote:
>> Phil Sorber writes:
>>> get_progname() returns a strdup()'d value. Shouldn't it then be simply
>>> char * and not const char *? Otherwise free() complains loudly without
>>> a cast.
>>
>> I
Dimitri Fontaine escribió:
> Robert Haas writes:
> > I have not tested the actual behavior of the latest patch, but I think
> > we want to define things so that the
> > pg_event_trigger_dropped_objects() function returns, specifically, the
> > list of objects dropped by the command which caused t
On Wed, Feb 6, 2013 at 9:38 AM, Alvaro Herrera wrote:
> Robert Haas escribió:
>> On Mon, Feb 4, 2013 at 5:50 PM, Alvaro Herrera
>> wrote:
>
>> > I propose to have a new subdirectory src/include/shared, and two
>> > header files:
>
>> > The frontend (pg_malloc) function definitions would live som
On Wed, Feb 6, 2013 at 9:36 AM, Dimitri Fontaine wrote:
> Robert Haas writes:
>> variable, it seems like there are a number of ways this can go wrong.
>
> Yeah, I think the current behavior might be surprising.
>
>> I have not tested the actual behavior of the latest patch, but I think
>> we want
Robert Haas escribió:
> On Mon, Feb 4, 2013 at 5:50 PM, Alvaro Herrera
> wrote:
> > I propose to have a new subdirectory src/include/shared, and two
> > header files:
> > The frontend (pg_malloc) function definitions would live somewhere in,
> > say, src/shared/fe_memutils.c. For the palloc()
Robert Haas writes:
> variable, it seems like there are a number of ways this can go wrong.
Yeah, I think the current behavior might be surprising.
> I have not tested the actual behavior of the latest patch, but I think
> we want to define things so that the
> pg_event_trigger_dropped_objects()
On Mon, Feb 4, 2013 at 5:50 PM, Alvaro Herrera wrote:
> There was some discussion about unifying backend and frontend
> code/headers for palloc et al, particularly so that programs that want
> to mix both can be easily compiled; see
> http://www.postgresql.org/message-id/20130118150629.gc29...@ala
On Tue, Feb 5, 2013 at 10:42 PM, Alvaro Herrera
wrote:
> A larger issue with the patch is handling of subxacts. A quick test
> doesn't reveal any obvious misbehavior, but having the list of objects
> dropped by a global variable might be problematic. What if, say, the
> event trigger function do
Alvaro Herrera writes:
> Hmm, quoth
> http://www.postgresql.org/message-id/23345.1358476...@sss.pgh.pa.us :
>
>> I'd really like to get to a point where we can
>> define things as happening like this:
>>
>> * collect information needed to interpret the DDL command
>> (lookup and loc
On 02/06/2013 08:09 AM, Dev Kumkar wrote:
Hello Everyone,
I am using postgres 9.2 and when executing function dblink facing a
fatal error while trying to execute dblink_connect as follows:
/SELECT * FROM dblink_connect('host=127.0.0.1 port=5432
dbname=postgres password=test')/
*ERROR*: co
Dev Kumkar wrote:
> I am using postgres 9.2 and when executing function dblink facing a fatal
> error while trying to
> execute dblink_connect as follows:
>
> SELECT * FROM dblink_connect('host=127.0.0.1 port=5432 dbname=postgres
> password=test')
>
> ERROR: could not establish connecti
Dimitri Fontaine escribió:
> Alvaro Herrera writes:
> > Well, I don't necessarily suggest that. But how about something like
> > this in performMultipleDeletions:
>
> [edited snippet of code]
>
> > /* invoke sql_drop triggers */
> > EventTriggerSQLDrop();
> >
> >
Hello Everyone,
I am using postgres 9.2 and when executing function dblink facing a fatal
error while trying to execute dblink_connect as follows:
* SELECT * FROM dblink_connect('host=127.0.0.1 port=5432 dbname=postgres
password=test')*
*ERROR*: could not establish connection DETAIL: FATA
2013/2/6 Miroslav Šimulčík :
>
>> "As fast as possible" and "PL/PgSQL function" don't go that well together.
>> PL/PgSQL is well and good for a great many jobs, but I doubt this is one of
>> them.
>
>
> Yes, I know. It was just example to demostrate functionality I need.
>
>> If you're willing to s
Alvaro Herrera writes:
> Well, I don't necessarily suggest that. But how about something like
> this in performMultipleDeletions:
[edited snippet of code]
> /* invoke sql_drop triggers */
> EventTriggerSQLDrop();
>
> /* EventTriggerSQLDropList remains s
> "As fast as possible" and "PL/PgSQL function" don't go that well together.
> PL/PgSQL is well and good for a great many jobs, but I doubt this is one of
> them.
>
Yes, I know. It was just example to demostrate functionality I need.
If you're willing to spend the time to do it, consider writing
On 02/06/2013 06:19 PM, Miroslav Šimulčík wrote:
> Hi all,
>
> I have deferred constraint update trigger in which I need to set same
> timestamp to all modified rows. The time needs to be the time of first
> invocation of this trigger fuction in transaciton. My intention is to
> set commit time to
>
> probably you can use a little bit cheaper session variables
>
I rejected session variables, because they don't get cleared at the end of
transaction if somebody set value on session level. So I can't decide if
new transaction started.
this is good (variable is cleared at the end of transactio
Dimitri Fontaine escribió:
> Alvaro Herrera writes:
> > I thought there was the idea that the list of objects to drop was to be
> > acquired before actually doing the deletion; so that the trigger
> > function could, for instance, get the name of the table being dropped.
> > I don't see that it wo
Alvaro Herrera writes:
> The bigger change I mentioned was the stuff in dependency.c -- I wasn't
> too happy about exposing the whole ObjectAddresses stuff to the outside
> world. The attached version only exposes simple accessors to let an
> external user of that to iterate on such arrays. Some
2013/2/6 Miroslav Šimulčík :
> This is not what I'm looking for. now() returns transaction start time. I
> need to set my own time anytime in transaction and then use that time later.
>
> Miro
>
>
> 2013/2/6 Misa Simic
>>
>> Hi,
>>
>>
>> I dont have access to pg at this moment... But:
>>
>> BEGIN;
This is not what I'm looking for. now() returns transaction start time. I
need to set my own time anytime in transaction and then use that time later.
Miro
2013/2/6 Misa Simic
> Hi,
>
>
> I dont have access to pg at this moment... But:
>
> BEGIN;
>
> SELECT now();
>
> SELECT clock_timestamp();
Hi,
I dont have access to pg at this moment... But:
BEGIN;
SELECT now();
SELECT clock_timestamp();
SELECT now();
SELECT pg_sleep(100);
SELECT now();
cCOMMIT;
Now() should always return the same, very first, result...
On Wednesday, February 6, 2013, Miroslav Šimulčík wrote:
> Hi all
Hi all,
I have deferred constraint update trigger in which I need to set same
timestamp to all modified rows. The time needs to be the time of first
invocation of this trigger fuction in transaciton. My intention is to set
commit time to rows modified in transaction.
So I need function that will
Alvaro Herrera writes:
> I thought there was the idea that the list of objects to drop was to be
> acquired before actually doing the deletion; so that the trigger
> function could, for instance, get the name of the table being dropped.
> I don't see that it works if we only provide
> pg_event_tri
90 matches
Mail list logo
