On Wed, Mar 28, 2012 at 8:52 AM, Robert Haas wrote:
> On Wed, Mar 28, 2012 at 11:28 AM, Dimitri Fontaine
> wrote:
>>> In practice, however, that sounds like a real pain in the neck. I
>>> would expect most people who were packaging extensions to handle a
>>> situation like this by forcing the us
On Tue, Feb 28, 2012 at 6:08 PM, Fujii Masao wrote:
> On Wed, Feb 8, 2012 at 1:33 AM, Magnus Hagander wrote:
>> Will it break using pg_basebackup 9.2 on a 9.1 server, though? that
>> would also be very useful in the scenario of the central server...
>
> No unless I'm missing something. Because pg
On 03/28/2012 09:12 PM, Joachim Wieland wrote:
On Thu, Mar 29, 2012 at 2:46 AM, Andrew Dunstan wrote:
But your patch hasn't got rid of them, and so it's declared twice. There is
no pgpipe.h, BTW, it's declared in port.h. If VC2005 doesn't complain about
the double declaration then that's a bu
Fujii Masao writes:
> On Thu, Mar 29, 2012 at 12:15 AM, Tom Lane wrote:
>> I think you need to tweak that to get the number to be right-justified
>> not left-justified.
> Unless I'm missing something, I did that because the patch uses %10s
> not %-10s. No?
Oh, you're right, I was misremembering
BTW, I forgot to mention that I did experiment with your python-based
test script for pg_stat_statements, but decided not to commit it.
There are just too many external dependencies for my taste:
1. python
2. psycopg2
3. dellstore2 test database
That coupled with the apparent impossibility of run
On Thu, Mar 29, 2012 at 12:15 AM, Tom Lane wrote:
> Fujii Masao writes:
>> This seems a simplest workaround. How about attached patch?
>
> I think you need to tweak that to get the number to be right-justified
> not left-justified.
Unless I'm missing something, I did that because the patch uses
Peter Eisentraut writes:
> There are some extensions that build with pgxs that use bison and flex.
> Their makefiles are set up to use the variables BISON and FLEX that pgxs
> provides. Except that that depends on how PostgreSQL was built. A
> binary package that was built in a clean chroot woul
Magnus Hagander writes:
> On Wed, Mar 28, 2012 at 18:12, Heikki Linnakangas
> wrote:
>> An obvious fix would be to call set_max_safe_fds() in the child processes,
>> although I wonder if that's too expensive. Another option is to pass down
>> the value with save_restore_backend_variables().
> IS
On Wed, Mar 28, 2012 at 1:46 PM, Robert Haas wrote:
> I'm wondering if we really need this much complexity around shutting
> down workers. I'm not sure I understand why we need both a "hard" and
> a "soft" method of shutting them down. At least on non-Windows
> systems, it seems like it would be
On Thu, Mar 29, 2012 at 2:46 AM, Andrew Dunstan wrote:
> But your patch hasn't got rid of them, and so it's declared twice. There is
> no pgpipe.h, BTW, it's declared in port.h. If VC2005 doesn't complain about
> the double declaration then that's a bug in the compiler, IMNSHO. Doesn't it
> even i
Peter Geoghegan writes:
> doc-patch is attached. I'm not sure if I got the balance right - it
> may be on the verbose side.
Thanks. I've committed the patch along with the docs, after rather
heavy editorialization.
There remain some loose ends that should be worked on but didn't seem
like commi
On 03/28/2012 08:28 PM, Joachim Wieland wrote:
On Wed, Mar 28, 2012 at 5:19 PM, Andrew Dunstan wrote:
First hurdle: It doesn't build under Windows/mingw-w64:
parallel.c:40:12: error: static declaration of 'pgpipe' follows
non-static declaration
Strange, I'm not seeing this but I'm bui
On Sat, Mar 24, 2012 at 10:49:07AM +0100, Boszormenyi Zoltan wrote:
> Sorry for the delay, I had been busy with other tasks and I rewrote this code
> to better cope with unknown result size, scrollable cursors and negative
> cursor positions.
>
> I think all points raised by Noah is addressed: per-
On Wed, Mar 28, 2012 at 5:19 PM, Andrew Dunstan wrote:
> First hurdle: It doesn't build under Windows/mingw-w64:
>
> parallel.c:40:12: error: static declaration of 'pgpipe' follows
> non-static declaration
Strange, I'm not seeing this but I'm building with VC2005. What
happens is that you're
On 29 March 2012 00:14, Tom Lane wrote:
> I'm planning to commit the patch with a USAGE_NON_EXEC_STICK value
> of 3.0, which is the largest value that stays below 10% wastage.
> We can twiddle that logic later, so if you want to experiment with an
> alternate decay rule, feel free.
I think I may
Peter Geoghegan writes:
> On 28 March 2012 15:57, Tom Lane wrote:
>> Is there any actual benefit in providing the
>> "pg_stat_statements.string_key" GUC? It looks to me more like something
>> that was thrown in because it was easy than because anybody would want
>> it. I'd just as soon leave it
On Wed, Mar 28, 2012 at 10:24 PM, Simon Riggs wrote:
> On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen wrote:
>> On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote:
>>> Master pg_controldata - OK txid_current_snapshot() - OK
>>> Standby pg_controldata - OK txid_current_snapshot() - lower va
On Wed, Mar 28, 2012 at 3:09 PM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>> Could you possibly generate a new diff to save me the trouble of
>> fixing the one you sent before?
>
> Please find it attached, it looks better now, and I rebased it against
> master for good measure (no conflicts)
On Wed, Mar 28, 2012 at 9:48 PM, Marko Kreen wrote:
> On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote:
>> Master pg_controldata - OK txid_current_snapshot() - OK
>> Standby pg_controldata - OK txid_current_snapshot() - lower value
>
> On Skytools list is report about master with slaves
On 03/28/2012 03:17 PM, Andrew Dunstan wrote:
On 03/28/2012 02:27 PM, Robert Haas wrote:
On Wed, Mar 28, 2012 at 2:20 PM, Alvaro Herrera
wrote:
Excerpts from Robert Haas's message of mié mar 28 14:46:30 -0300 2012:
I keep hoping someone who knows Windows is going to take a look at
this,
Hello
2012/3/28 Heikki Linnakangas :
> Ok, seems that the API issue is settled, so I'm now looking at the code
> actually doing the checking. My first impression is that this is a lot of
> code. Can we simplify it?
>
I am afraid so there are not a big space for simplification :(
> Since this is
On Fri, Mar 23, 2012 at 08:52:40AM +, Simon Riggs wrote:
> Master pg_controldata - OK txid_current_snapshot() - OK
> Standby pg_controldata - OK txid_current_snapshot() - lower value
On Skytools list is report about master with slaves, but the
lower value appears on master too:
http://lists
Robert Haas writes:
> Further thought: I think maybe we shouldn't use keywords at all for
> this, and instead use descriptive strings like post-parse or
> pre-execution or command-start, because I bet in the end we're going
> to end up with a bunch of them (create-schema-subcommand-start?
> alter-
On 03/28/2012 02:27 PM, Robert Haas wrote:
On Wed, Mar 28, 2012 at 2:20 PM, Alvaro Herrera
wrote:
Excerpts from Robert Haas's message of mié mar 28 14:46:30 -0300 2012:
I keep hoping someone who knows Windows is going to take a look at
this, but so far no luck. It could also really use som
On Wed, Mar 28, 2012 at 2:20 PM, Alvaro Herrera
wrote:
> Excerpts from Robert Haas's message of mié mar 28 14:46:30 -0300 2012:
>> I keep hoping someone who knows Windows is going to take a look at
>> this, but so far no luck. It could also really use some attention
>> from someone who has an act
Excerpts from Robert Haas's message of mié mar 28 14:46:30 -0300 2012:
> I keep hoping someone who knows Windows is going to take a look at
> this, but so far no luck. It could also really use some attention
> from someone who has an actual really big database handy, to see how
> successful it i
There are some extensions that build with pgxs that use bison and flex.
Their makefiles are set up to use the variables BISON and FLEX that pgxs
provides. Except that that depends on how PostgreSQL was built. A
binary package that was built in a clean chroot would probably not have
those variable
On Sun, Mar 25, 2012 at 10:50 PM, Joachim Wieland wrote:
> On Fri, Mar 23, 2012 at 11:11 AM, Alvaro Herrera
> wrote:
>> Are you going to provide a rebased version?
>
> Rebased version attached, this patch also includes Robert's earlier
> suggestions.
I keep hoping someone who knows Windows is g
On mån, 2012-03-26 at 15:53 -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On mån, 2012-03-26 at 15:15 -0400, Tom Lane wrote:
> >> I also do not think it does anything for readability for this call
> >> of read_info() to be unexpectedly unlike all the others.
>
> > I do not think that it
On 28 March 2012 15:57, Tom Lane wrote:
> Is there any actual benefit in providing the
> "pg_stat_statements.string_key" GUC? It looks to me more like something
> that was thrown in because it was easy than because anybody would want
> it. I'd just as soon leave it out and avoid the incremental
On Wed, Mar 28, 2012 at 12:11 PM, Dimitri Fontaine
wrote:
>> On a more prosaic note, you seem to have made a mistake when
>> generating the v5 diff. It includes reverts of a couple of unrelated,
>> recent patches.
>
> Ouch. It seems to happen to me too often. I probably need to get the
> shallow
On Wed, Mar 28, 2012 at 18:12, Heikki Linnakangas
wrote:
> At postmaster startup, we determine the maximum number of open files we can
> handle by trying to open a lot of file descriptors, up to
> max_files_per_process. This is done in set_max_safe_fds(), and the
> determined max_safe_fds value is
On Wed, Mar 28, 2012 at 8:47 AM, Robert Haas wrote:
>>>
>>> $ ./pg_archivecleanup -x "bz2" /tmp 000100010058
>>
>> Hmm, but I thought that the idea was that the extension was optional.
>> Perhaps I'm missing something but I don't think the previous patch
>> will complain about that eit
At postmaster startup, we determine the maximum number of open files we
can handle by trying to open a lot of file descriptors, up to
max_files_per_process. This is done in set_max_safe_fds(), and the
determined max_safe_fds value is inherited by child processes at fork().
However, with EXEC_BA
Robert Haas writes:
> accomplish. Instead, you're just concerned about allowing some but
> not all versions of package A to provide feature F, so that other
> extensions can depend on F to get the specific version of A that they
> need (and not, as I had assumed, so that they can get either A or
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 Wed, Mar 28, 2012 at 11:28 AM, Dimitri Fontaine
wrote:
>> In practice, however, that sounds like a real pain in the neck. I
>> would expect most people who were packaging extensions to handle a
>> situation like this by forcing the user to provide the name of the
>> function to be called, eith
Robert Haas writes:
> I'm not completely convinced that the case has been made that this is
> a useful thing to have.
You're basically saying that the current lack of extension distribution
is a good reason for not building the tools allowing to create said
distribution. WTF?
(PGXN uses the wo
Fujii Masao writes:
> This seems a simplest workaround. How about attached patch?
I think you need to tweak that to get the number to be right-justified
not left-justified.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Wed, Mar 28, 2012 at 9:40 PM, Robert Haas wrote:
> I think it would make sense to rearrange that so that we don't have
> two tests for ztarfile != NULL; do that test first, and then if it
> fails, do the strcmp after that.
Makes sense.
> Also, if we're going to test the return value of fclose
On Wed, Mar 28, 2012 at 10:46 AM, Jaime Casanova wrote:
> On Wed, Mar 28, 2012 at 8:29 AM, Robert Haas wrote:
>> I think the problem is that the UPDATE or DELETE can only fire once a
>> matching row has been identified, so that OLD can be filled in
>> appropriately. But in this case, the matchin
On Thu, Mar 22, 2012 at 2:08 PM, Dimitri Fontaine
wrote:
> Alvaro Herrera writes:
>> get_available_versions_for_extension seems to contain a bunch of
>> commented-out lines ...
>
> Damn. Sorry about that. Here's a cleaned-up version of the patch.
I'm not completely convinced that the case has b
A couple other issues about this patch ...
Is there any actual benefit in providing the
"pg_stat_statements.string_key" GUC? It looks to me more like something
that was thrown in because it was easy than because anybody would want
it. I'd just as soon leave it out and avoid the incremental API
c
On Wed, Mar 28, 2012 at 8:29 AM, Robert Haas wrote:
>
> I think the problem is that the UPDATE or DELETE can only fire once a
> matching row has been identified, so that OLD can be filled in
> appropriately. But in this case, the matching row gets found not in
> the parent table, but in one of it
On 28 March 2012 15:25, Tom Lane wrote:
> That's been an issue right along for cases such as EXPLAIN and EXECUTE,
> I believe.
Possible, since I didn't have test coverage for either of those 2 commands.
Perhaps the right thing is to consider such executor calls
> as nested statements --- that i
On Wed, Mar 28, 2012 at 09:45:29AM -0400, Robert Haas wrote:
> On Tue, Mar 27, 2012 at 1:36 PM, Robert Haas wrote:
> > Let's split the difference: how about we close it a week from this
> > Friday. ?That would be April 6, 2012, ten days from today.
>
> Anybody, anybody? Can we try to get some ag
On Wed, Mar 28, 2012 at 9:19 PM, Robert Haas wrote:
> On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao wrote:
>> On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas wrote:
>>> pg_test_timing utility, to measure clock monotonicity and timing cost.
>>
>> When I compiled this, I got a compiler warning. Attac
Robert Haas writes:
> I'm coming around to the point of view that we should just make
> pg_terminate_backend()'s behavior consistent with pg_cancel_backend()
> and call it good.
Yeah, the issues that are really of concern are not ones that that
function in itself can address.
Peter Geoghegan writes:
> I merged upstream changes with the intention of providing a new patch
> for you to review. I found a problem that I'd guess was introduced by
> commit 9dbf2b7d75de5af38d087cbe2b1147dd0fd10f0a, "Restructure SELECT
> INTO's parsetree representation into CreateTableAsStmt".
Il giorno lun, 19/03/2012 alle 18.41 +0100, Marco Nenciarini ha scritto:
>
> Attached is v5, which should address all the remaining issues.
Please find attached v6 of the EACH Foreign Key patch. From v5 only
cosmetic changes to the documentation were made.
Regards,
Marco
--
Marco Nenciarini -
On Thu, Mar 22, 2012 at 6:07 PM, Peter Geoghegan wrote:
> On 23 January 2012 02:08, Robert Haas wrote:
>> On Sat, Jan 21, 2012 at 6:32 PM, Jeff Janes wrote:
>>> I'm finding the backend_writes column pretty unfortunate. The only
>>> use I know of for it is to determine if the bgwriter is lagging
On Wed, Mar 28, 2012 at 10:02 AM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Andres Freund wrote:
>>> On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
As Tom pointed out, if there's another person sharing the user ID
you're using, and you don't trust them, their ability
Robert Haas writes:
> On Tue, Mar 27, 2012 at 1:36 PM, Robert Haas wrote:
>> Let's split the difference: how about we close it a week from this
>> Friday. That would be April 6, 2012, ten days from today.
> Anybody, anybody? Can we try to get some agreement on this?
Works for me.
Ants Aasma writes:
> A user complained on pgsql-performance that SELECT col FROM table
> GROUP BY col LIMIT 2; performs a full table scan. ISTM that it's safe
> to return tuples from hash-aggregate as they are found when no
> aggregate functions are in use. Attached is a first shot at that.
As I
On 27 March 2012 20:26, Tom Lane wrote:
> Have yet to look at the pg_stat_statements code itself.
I merged upstream changes with the intention of providing a new patch
for you to review. I found a problem that I'd guess was introduced by
commit 9dbf2b7d75de5af38d087cbe2b1147dd0fd10f0a, "Restructu
"Kevin Grittner" writes:
> Andres Freund wrote:
>> On Tuesday, March 27, 2012 07:51:59 PM Kevin Grittner wrote:
>>> As Tom pointed out, if there's another person sharing the user ID
>>> you're using, and you don't trust them, their ability to cancel
>>> your session is likely way down the list of
On Wed, Mar 28, 2012 at 2:45 PM, Robert Haas wrote:
> On Tue, Mar 27, 2012 at 1:36 PM, Robert Haas wrote:
>> On Mon, Mar 26, 2012 at 7:39 PM, Tom Lane wrote:
Fine. What do you propose, specifically?
>>>
>>> The end of the month is coming up. How about we propose to close the
>>> 'fest on A
On Sun, Jan 1, 2012 at 11:37 PM, Peter Eisentraut wrote:
> One thing that I'm concerned about with this is that it treats a plain
> RETURN in a BEFORE trigger as RETURN NULL, whereas arguably it should be
> an error. I haven't found a good way to handle that yet, but I'll keep
> looking.
I would
On Fri, Feb 3, 2012 at 10:28 AM, Robert Haas wrote:
> On Wed, Feb 1, 2012 at 2:39 PM, Simon Riggs wrote:
>> On Wed, Feb 1, 2012 at 7:31 PM, Peter Eisentraut wrote:
>>> On sön, 2012-01-29 at 22:01 +, Simon Riggs wrote:
Patch now locks index in AccessExclusiveLock in final stage of drop.
On Mon, Mar 5, 2012 at 11:55 AM, Simon Riggs wrote:
> On Sun, Mar 4, 2012 at 1:20 AM, Jeff Janes wrote:
>> Does this patch have any user-visible effect? I thought it would make
>> pg_last_xact_replay_timestamp() advance, but it does not seem to. I
>> looked through the source a bit, and as best
On Sun, Mar 11, 2012 at 9:28 PM, Robert Haas wrote:
> On Sat, Mar 10, 2012 at 2:38 PM, Jaime Casanova wrote:
>> On Fri, Mar 9, 2012 at 9:07 AM, Robert Haas wrote:
>>> On Fri, Mar 9, 2012 at 12:47 AM, Jaime Casanova
>>> wrote:
> Sorry, here's the patch rebased and with the suggestion from A
On Tue, Mar 27, 2012 at 1:36 PM, Robert Haas wrote:
> On Mon, Mar 26, 2012 at 7:39 PM, Tom Lane wrote:
>>> Fine. What do you propose, specifically?
>>
>> The end of the month is coming up. How about we propose to close the
>> 'fest on April 1st? Anything that's not committable by then goes to
>
On Wed, Mar 28, 2012 at 9:16 AM, Jaime Casanova wrote:
> On Wed, Mar 28, 2012 at 1:21 AM, Jaime Casanova wrote:
>> Hi,
>>
>> i was trying to create triggers that redirect INSERT/UPDATE/DELETE
>> actions from parent to childs, but found that UPDATE/DELETE doesn't
>> get redirected. Actually, the t
On Wed, Mar 28, 2012 at 1:21 AM, Jaime Casanova wrote:
> Hi,
>
> i was trying to create triggers that redirect INSERT/UPDATE/DELETE
> actions from parent to childs, but found that UPDATE/DELETE doesn't
> get redirected. Actually, the triggers BEFORE UPDATE and BEFORE DELETE
> aren't even fired.
>
On Wed, Mar 28, 2012 at 08:57:42AM -0400, Robert Haas wrote:
> On Wed, Mar 28, 2012 at 8:51 AM, Marko Kreen wrote:
> >> How about: ".. %10" INT64_FORMAT " .. " ?
> >
> > Well, it won't work because unlike , Postgres *_FORMAT
> > includes '%' in it.
> >
> > I guess that why does not do it...
>
>
(2012/03/28 21:07), Albe Laurenz wrote:
> I found another limitation of this approach:
> pgsql_fdw_analyze() has to run as a user who can update
> pg_statistic, and this user needs a user mapping to a remote
> user who can read pg_statistic.
>
> This is not necessary for normal operation and needs
On Wed, Mar 28, 2012 at 8:51 AM, Marko Kreen wrote:
>> How about: ".. %10" INT64_FORMAT " .. " ?
>
> Well, it won't work because unlike , Postgres *_FORMAT
> includes '%' in it.
>
> I guess that why does not do it...
Hmm, I guess we could change that, but it would create a hazard for
thirty-par
On Wed, Mar 28, 2012 at 03:46:26PM +0300, Marko Kreen wrote:
> On Wed, Mar 28, 2012 at 08:19:37AM -0400, Robert Haas wrote:
> > On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao wrote:
> > > On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas wrote:
> > >> pg_test_timing utility, to measure clock monotonici
On Wed, Mar 28, 2012 at 08:19:37AM -0400, Robert Haas wrote:
> On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao wrote:
> > On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas wrote:
> >> pg_test_timing utility, to measure clock monotonicity and timing cost.
> >
> > When I compiled this, I got a compiler wa
On Tue, Mar 27, 2012 at 5:25 AM, Fujii Masao wrote:
>> fprintf(stderr, _("%s: could not identify system: %s\n"),
>> progname, PQerrorMessage(conn));
>
> Since PQerrorMessage() result includes a trailing newline, the above
> log message in pg_basebackup doesn't need to i
On Tue, Mar 27, 2012 at 7:13 AM, Fujii Masao wrote:
> Attached patch removes the fflush() part, changes the log message and removes
> the check of tarfile, as above.
With this patch applied, we end up with:
if (strcmp(basedir, "-") == 0)
{
#ifdef HAVE_LIBZ
(2012/03/28 16:18), Albe Laurenz wrote:
> I wrote:
>>> How about getting # of rows estimate by executing EXPLAIN for
>>> fully-fledged remote query (IOW, contains pushed-down WHERE clause),
> and
>>> estimate selectivity of local filter on the basis of the statistics
>>> which are generated by FDW
On Tue, Mar 27, 2012 at 10:10 PM, Fujii Masao wrote:
> On Wed, Mar 28, 2012 at 5:17 AM, Robert Haas wrote:
>> pg_test_timing utility, to measure clock monotonicity and timing cost.
>
> When I compiled this, I got a compiler warning. Attached patch
> silences the warning.
Unfortunately, that *pro
On Wed, Mar 28, 2012 at 7:16 AM, Robert Haas wrote:
>> Now I can see why implementing that on top of the ANY command feature is
>> surprising enough for wanting to not do it this way. Maybe the answer is
>> to use another keyword to be able to register command triggers that run
>> that early and w
On Wed, Mar 28, 2012 at 4:12 AM, Dimitri Fontaine
wrote:
> Robert Haas writes:
>>> I think BEFORE command triggers ideally should run
>>> * before permission checks
>>> * before locking
>>> * before internal checks are done (nameing conflicts, type checks and such)
>>
>> It is possible to do this
On 28 March 2012 08:39, Thom Brown wrote:
> On 28 March 2012 08:13, Thom Brown wrote:
>> 2012/3/28 Shigeru HANADA :
>>> (2012/03/27 20:32), Thom Brown wrote:
2012/3/26 Shigeru HANADA:
> * pgsql_fdw_v17.patch
> - Adds pgsql_fdw as contrib module
> * pgsql_fdw_pushdown_v10.patc
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
Ok, seems that the API issue is settled, so I'm now looking at the code
actually doing the checking. My first impression is that this is a lot
of code. Can we simplify it?
Since this is deeply integrated into the PL/pgSQL interpreter, I was
expecting that this would run through the normal inte
[ also for the archives' sake ]
On 27 March 2012 22:05, Tom Lane wrote:
> Well, testing function pointers for null is certainly OK --- note that
> all our hook function call sites do that. It's true that testing for
> equality to a particular function's name can fail on some platforms
> because
Robert Haas writes:
>> I think BEFORE command triggers ideally should run
>> * before permission checks
>> * before locking
>> * before internal checks are done (nameing conflicts, type checks and such)
>
> It is possible to do this, and it would actually be much easier and
> less invasive to impl
On 28 March 2012 08:13, Thom Brown wrote:
> 2012/3/28 Shigeru HANADA :
>> (2012/03/27 20:32), Thom Brown wrote:
>>> 2012/3/26 Shigeru HANADA:
* pgsql_fdw_v17.patch
- Adds pgsql_fdw as contrib module
* pgsql_fdw_pushdown_v10.patch
- Adds WHERE push down capability to pgs
2012/3/28 Shigeru HANADA :
> (2012/03/27 20:32), Thom Brown wrote:
>> 2012/3/26 Shigeru HANADA:
>>> * pgsql_fdw_v17.patch
>>> - Adds pgsql_fdw as contrib module
>>> * pgsql_fdw_pushdown_v10.patch
>>> - Adds WHERE push down capability to pgsql_fdw
>>> * pgsql_fdw_analyze_v1.patch
>>> - A
82 matches
Mail list logo
