On Thu, Aug 14, 2014 at 1:49 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
I'd like to propose to add new option --immediate to pg_ctl promote.
When this option is set, recovery ignores any WAL data which have not
been replayed yet and exits immediately. Patch attached.
This promotion
Hi all,
Currently pg_dump does not allow a user to specify an exported snapshot
name that he would like to use for a dump using SET TRANSACTION SNAPSHOT
(now pg_export_snapshot is only used for parallel pg_dump within it). I
imagine that this would be handy to take a consistent dump of a given
On Sat, Aug 30, 2014 at 11:32 PM, Noah Misch n...@leadboat.com wrote:
On Tue, Aug 26, 2014 at 10:17:05AM +0100, Dave Page wrote:
On Tue, Aug 26, 2014 at 1:46 AM, Tom Lane t...@sss.pgh.pa.us wrote:
For the last month or so, these two buildfarm animals (which I believe are
the same physical
--On 1. September 2014 17:00:32 +0900 Michael Paquier
michael.paqu...@gmail.com wrote:
Currently pg_dump does not allow a user to specify an exported snapshot
name that he would like to use for a dump using SET TRANSACTION SNAPSHOT
(now pg_export_snapshot is only used for parallel pg_dump
On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/28/2014 07:28 PM, Alexey Klyukin wrote:
On Mon, Aug 25, 2014 at 12:02 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/24/2014 03:11 PM, Alexey Klyukin wrote:
On Wed, Aug 20, 2014 at
Hi,
For those of you who use PL/pgSQL every day, I'm quite certain you all feel
there are a number of things you would like to change in the language, but
realize it cannot be achieved without possibly breaking compatibility, at
least in theory. Even though you own code would survive the change,
On Sat, Jul 26, 2014 at 8:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Basically my point is that this just seems like inventing another way to
do what one can already do with RAISE, and it doesn't have much redeeming
social value to justify the cognitive load of inventing another construct.
The
On 2014-09-01 11:04:53 +0200, Joel Jacobson wrote:
For those of you who use PL/pgSQL every day, I'm quite certain you all feel
there are a number of things you would like to change in the language, but
realize it cannot be achieved without possibly breaking compatibility, at
least in theory.
Hi,
On 2014-09-01 10:25:58 +0200, Bernd Helmle wrote:
--On 1. September 2014 17:00:32 +0900 Michael Paquier
michael.paqu...@gmail.com wrote:
Currently pg_dump does not allow a user to specify an exported snapshot
name that he would like to use for a dump using SET TRANSACTION SNAPSHOT
(now
On Thu, Aug 28, 2014 at 9:34 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
2014-08-28 14:22 GMT+02:00 Fujii Masao masao.fu...@gmail.com:
On Thu, Aug 28, 2014 at 5:48 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
comments?
+fprintf(output, _( ECHO control what
On 09/01/2014 11:24 AM, Andres Freund wrote:
On 2014-09-01 11:04:53 +0200, Joel Jacobson wrote:
For those of you who use PL/pgSQL every day, I'm quite certain you all feel
there are a number of things you would like to change in the language, but
realize it cannot be achieved without possibly
On 2014-08-30 14:22:40 +0200, Andres Freund wrote:
Hi,
when profiling optimized builds (linux, gcc 4.9) it's currently
LWLockAcquireCommon() showing up, not it's callers. Instruction level
profiles show that the tests for valptr show up in profiles to some
extent. Since most callers don't
On 9/1/14 11:53 AM, Hannu Krosing wrote:
On 09/01/2014 11:24 AM, Andres Freund wrote:
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.
You're going to have to find a more gradual way of doing this.
Probably a better way (and
On Mon, Sep 1, 2014 at 11:24 AM, Andres Freund and...@2ndquadrant.com wrote:
-many.
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.
You're going to have to find a more gradual way of doing this.
I agree this is a valid
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA functionality, or pl/pgsql specific
LOCAL SET to
On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com wrote:
The patch looks good to me. One minor comment is; probably you need to
update the tab-completion code.
Thanks for the review. I have updated
On 09/01/2014 12:00 PM, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
On 09/01/2014 11:24 AM, Andres Freund wrote:
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.
You're going to have to find a more
Hi Pavel,
Patch does look good to me. And found no issues as such.
However here are my optional suggestions:
1. Frankly, I did not like name of the function row_to_json_pretty_choosy.
Something like row_to_json_pretty_ignore_nulls seems better to me.
2. To use ignore nulls feature, I have to
On 9/1/14 12:12 PM, Andres Freund wrote:
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been some talk of it) is
having some kind of PRAGMA
On Mon, Sep 1, 2014 at 12:32 PM, Hannu Krosing ha...@2ndquadrant.com wrote:
it would be
...
[ WITH ( [LOCAL] attribute [, ...] ) ]
where LOCAL attributes are _not_ inherited by nested functions
but the LOCALs would shadow globals in the function definitions
that have them.
I know it
On 09/01/2014 05:24 PM, Andres Freund wrote:
Look at the *disaster* the few minor changes in python3 were. It's now,
years after, only starting to get used again.
While that's valid, I'd like to point out that Python2 and Python3 don't
share a runtime and can't easily use each others' modules
On 2014-09-01 12:49:22 +0200, Marko Tiikkaja wrote:
On 9/1/14 12:12 PM, Andres Freund wrote:
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
Probably a better way (and there has been
Hi all
Before I have a go at hacking it together I wanted to check: Has anyone
explored modifying crosstab to return a refcursor, so you can FETCH the
results w/o having to specify an explicit result type/descriptor?
Consuming the input in another query is more of a pain, but it'd be
infinitely
On Wed, Aug 27, 2014 at 11:02 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
On Tue, Aug 26, 2014 at 5:12 PM, Andres Freund and...@anarazel.de wrote:
On 2014-08-26 12:44:43 +0900, Michael Paquier wrote:
I always was of the opinion that a exclusive lock is still *MUCH* better
than what we
On Mon, Sep 1, 2014 at 3:23 PM, Amit Kapila amit.kapil...@gmail.com wrote:
On Thu, Aug 14, 2014 at 1:49 PM, Fujii Masao masao.fu...@gmail.com wrote:
Hi,
I'd like to propose to add new option --immediate to pg_ctl promote.
When this option is set, recovery ignores any WAL data which have not
While working on [1], I've found that postgres_fdw behaves oddly:
postgres=# create foreign table ft (a int) server loopback options
(table_name 't');
CREATE FOREIGN TABLE
postgres=# select tableoid, * from ft;
tableoid | a
--+---
16400 | 1
(1 row)
postgres=# select tableoid, * from
On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund and...@2ndquadrant.com wrote:
The likelihood of us now knowing all the things that we want to break
rigth now seems about zero. There *will* be further ones. If we go with
the approach of creating new language versions for all of them we'll end
up
Hi
2014-09-01 11:04 GMT+02:00 Joel Jacobson j...@trustly.com:
Hi,
For those of you who use PL/pgSQL every day, I'm quite certain you all
feel there are a number of things you would like to change in the language,
but realize it cannot be achieved without possibly breaking compatibility,
2014-09-01 13:30 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund and...@2ndquadrant.com
wrote:
The likelihood of us now knowing all the things that we want to break
rigth now seems about zero. There *will* be further ones. If we go with
the
Hi
2014-09-01 13:08 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
Hi all
Before I have a go at hacking it together I wanted to check: Has anyone
explored modifying crosstab to return a refcursor, so you can FETCH the
results w/o having to specify an explicit result type/descriptor?
+1
Hello,
I found this issue when trying per-pg_user (role) loading of
auto_analyze and some tweaking tool. It is not necessarily set by
the user by own, but the function to decide whether to load some
module by the session-user would be usable, at least, as for me:)
I think we could just
On Sun, Aug 31, 2014 at 10:45 PM, Magnus Hagander mag...@hagander.net wrote:
As this is a number of patches rolled into one - do you happen to keep
them separate in your local repo? If so can you send them as separate
ones (refactor identify_system should be quite unrelated to supporting
On 2014-09-01 20:58:29 +0900, Michael Paquier wrote:
On Sun, Aug 31, 2014 at 10:45 PM, Magnus Hagander mag...@hagander.net wrote:
As this is a number of patches rolled into one - do you happen to keep
them separate in your local repo? If so can you send them as separate
ones (refactor
On 8/29/14 4:33 PM, Tom Lane wrote:
So either it has to be inside
ModifyTable or the ModifyTable has to somehow pass something to a Limit
node on top of it
... or we add a LockRows node below the Limit node. Yeah, that would make
UPDATE/LIMIT a tad slower, but I think that might be preferable
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I agree with Andres - it is not a good for plpgsql and for plpgsql users.
The benefit must be significant for 90% of users.
...
Official implementation of plpgsql2 can be very wrong and dangerous signal -
so we should
2014-09-01 14:27 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I agree with Andres - it is not a good for plpgsql and for plpgsql users.
The benefit must be significant for 90% of users.
...
Official implementation
On Mon, Sep 1, 2014 at 6:30 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-01 10:25:58 +0200, Bernd Helmle wrote:
There was a discussion of this kind of feature some time ago here:
On 09/01/2014 12:55 PM, Andres Freund wrote:
On 2014-09-01 12:49:22 +0200, Marko Tiikkaja wrote:
On 9/1/14 12:12 PM, Andres Freund wrote:
On 2014-09-01 12:00:48 +0200, Marko Tiikkaja wrote:
On 9/1/14 11:53 AM, Hannu Krosing wrote:
You're going to have to find a more gradual way of doing this.
On 2014-09-01 21:54:24 +0900, Michael Paquier wrote:
On Mon, Sep 1, 2014 at 6:30 PM, Andres Freund and...@2ndquadrant.com wrote:
I was never convinced of the reasoning in that thread. Possibly things
have changed enough now that logical decoding is in core...
Well, the test case I got in
On 9/1/14 2:53 PM, Pavel Stehule wrote:
2014-09-01 14:27 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I agree with Andres - it is not a good for plpgsql and for plpgsql users.
The benefit must be significant for 90% of
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
It bad signal to have two languages plpgsql and plpgsql2. Who will believe
to us so we will continue development of plpgsql?
Depends on how you define development.
Bugfixes of plpgsql? Yes, of course.
New features? No,
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
It bad signal to have two languages plpgsql and plpgsql2. Who will believe
to us so we will continue development of plpgsql?
Depends on how you define
On Fri, Aug 29, 2014 at 6:33 PM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/28/2014 02:46 PM, Fujii Masao wrote:
On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
On 08/25/2014 10:48 PM, Heikki Linnakangas wrote:
Actually, perhaps it would be
On 08/25/2014 02:36 PM, Sawada Masahiko wrote:
Hi all,
Attached WIP patch adds -C (--concurrently) option for reindexdb
command for concurrently reindexing.
If we specify -C option with any table then reindexdb do reindexing
concurrently with minimum lock necessary.
Note that we cannot use
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
Just like with plpgsql, once released, plpgsql2 cannot break
compatibility with future versions, so we only have one chance to
carefully think though what we would like to change in the language.
You're not proposing to copy plpgsql's runtime
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
From the top of my head, these are Things I personally would want to see
in plpgsql2:
Oh, also, I'd *love* to improve how non-plannable statements with
PL/PgSQL variable subsitutions behave.
*I* understand why the following is wrong:
DO
$$
DECLARE
On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao masao.fu...@gmail.com wrote:
On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila amit.kapil...@gmail.com
wrote:
On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao masao.fu...@gmail.com
wrote:
The patch looks good to me. One minor comment is; probably you need
2014-09-01 15:12 GMT+02:00 Marko Tiikkaja ma...@joh.to:
On 9/1/14 2:53 PM, Pavel Stehule wrote:
2014-09-01 14:27 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
I agree with Andres - it is not a good for plpgsql and
2014-09-01 15:52 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
From the top of my head, these are Things I personally would want to see
in plpgsql2:
Oh, also, I'd *love* to improve how non-plannable statements with
PL/PgSQL variable
On 09/01/2014 09:58 PM, Pavel Stehule wrote:
It is in ToDo - allow parametrization for COMMANDs.
But this is one point, when I am not sure if we would it. Now -
situation is very simply. Variables should not be used as table or
column name. With your proposal, the situation will by much
2014-09-01 16:01 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/01/2014 09:58 PM, Pavel Stehule wrote:
It is in ToDo - allow parametrization for COMMANDs.
But this is one point, when I am not sure if we would it. Now -
situation is very simply. Variables should not be used as
On 2014-09-01 22:01:33 +0800, Craig Ringer wrote:
On 09/01/2014 09:58 PM, Pavel Stehule wrote:
It is in ToDo - allow parametrization for COMMANDs.
But this is one point, when I am not sure if we would it. Now -
situation is very simply. Variables should not be used as table or
On 09/01/2014 10:11 PM, Pavel Stehule wrote:
It can be solution, but I dislike it .. It increase a language
complexity .. vars with or without prefix .. and more, hidden dynamic SQL
Nothing what I like - I have a mental barrier to this concept.
Yeah - the question is whether it's better
On 09/01/2014 10:17 PM, Andres Freund wrote:
Imo this is still something that's more dynamic SQL (i.e. EXECUTE's
remit) than something that shouldn't be doable implicitly. So perhaps
the solution is to extend EXECUTE to allow specifying tablenames as
variables more conveniently?
With
2014-09-01 16:18 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/01/2014 10:11 PM, Pavel Stehule wrote:
It can be solution, but I dislike it .. It increase a language
complexity .. vars with or without prefix .. and more, hidden dynamic
SQL
Nothing what I like - I have a mental
On 2014-09-01 22:20:37 +0800, Craig Ringer wrote:
On 09/01/2014 10:17 PM, Andres Freund wrote:
Imo this is still something that's more dynamic SQL (i.e. EXECUTE's
remit) than something that shouldn't be doable implicitly. So perhaps
the solution is to extend EXECUTE to allow specifying
On 09/01/2014 10:24 PM, Andres Freund wrote:
I know of format(), but it doesn't allow you to pass parameters as
actual query variables unfortunately.
I'm wondering if there's a way to marry USING and format()...
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING
On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It bad signal to have two languages plpgsql and plpgsql2. Who will believe
to us so we
+1
I use underscore for *all* variables and input parameters in all
functions. Making that a requirement in plpgsql2 wouldn't break any of
my code.
On Mon, Sep 1, 2014 at 3:52 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
From the top of my head,
2014-09-01 16:26 GMT+02:00 Craig Ringer cr...@2ndquadrant.com:
On 09/01/2014 10:24 PM, Andres Freund wrote:
I know of format(), but it doesn't allow you to pass parameters as
actual query variables unfortunately.
I'm wondering if there's a way to marry USING and format()...
Well, the
On 09/01/2014 03:45 PM, Craig Ringer wrote:
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
Just like with plpgsql, once released, plpgsql2 cannot break
compatibility with future versions, so we only have one chance to
carefully think though what we would like to change in the language.
You're
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we need a new language.
All the clumsy stuff we cannot fix in plpgsql,
On 2014-09-01 16:29:18 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund and...@2ndquadrant.com wrote:
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It bad signal to have two
On 09/01/2014 05:41 PM, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer cr...@2ndquadrant.com wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we need a new language.
2014-09-01 16:39 GMT+02:00 Hannu Krosing ha...@2ndquadrant.com:
On 09/01/2014 03:45 PM, Craig Ringer wrote:
On 09/01/2014 05:04 PM, Joel Jacobson wrote:
Just like with plpgsql, once released, plpgsql2 cannot break
compatibility with future versions, so we only have one chance to
2014-09-01 16:41 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer cr...@2ndquadrant.com
wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we
Michael Paquier michael.paqu...@gmail.com writes:
I just tested the patch and this feature works as expected if timing
is on and it displays the individual run time of each query kicked by
\watch. Note that --echo-hidden does not display the query run during
each loop and that this is contrary
On Mon, Sep 1, 2014 at 4:41 PM, Andres Freund and...@2ndquadrant.com wrote:
I'm just saying it's much less probable you can add new features to
plpgsql than to plpgsql2, as you have to take into account the risk of
breaking compatibility.
That's just a difference of one release. The release
On 09/01/2014 10:41 PM, Joel Jacobson wrote:
This is exactly why we need a new language.
All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in
plpgsql2, with the most beautiful syntax we can come up with.
I guess it's a question if we want to support things like this. If we
On Mon, Sep 1, 2014 at 5:16 PM, Craig Ringer cr...@2ndquadrant.com wrote:
On 09/01/2014 10:41 PM, Joel Jacobson wrote:
This is exactly why we need a new language.
All the clumsy stuff we cannot fix in plpgsql, can easily be fixed in
plpgsql2, with the most beautiful syntax we can come up with.
Joel Jacobson-2 wrote
On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer lt;
craig@
gt; wrote:
Well, the idiom:
EXECUTE format(SELECT %I FROM %I WHERE $1, col, tbl) USING val;
is not lovely. It works, but it's clumsy.
This is exactly why we need a new language.
All the clumsy stuff we
Hi everbody,
My first mail to this one, so please be mild. I fired up the debugger to get
this item going, which is also on the Todo List.
Attached is a very trivial patch as a basis for discussion that at least makes
\s (show history) work in psql on Macs. Macs uses libedit, which has a
Andres Freund and...@2ndquadrant.com writes:
On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule pavel.steh...@gmail.com
wrote:
It bad signal to have two languages plpgsql and plpgsql2. Who will believe
to us so we will continue development of
On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Aside from costing planning time, most likely that would forever prevent
us from pushing some types of intelligence about partitioning into the
executor.
How would it affect this calculus if there were partitioned indexes
On 2014-08-29 20:12:16 +0200, Hannu Krosing wrote:
It would need to replace plain tid (pagenr, tupnr) with triple of (partid,
pagenr, tupnr).
Cross-partition indexes are especially needed if we want to allow putting
UNIQUE constraints on non-partition-key columns.
I actually don't think
Greg Stark st...@mit.edu writes:
On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Aside from costing planning time, most likely that would forever prevent
us from pushing some types of intelligence about partitioning into the
executor.
How would it affect this calculus if
On Fri, Aug 29, 2014 at 12:39 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Haribabu Kommi kommi.harib...@gmail.com writes:
Thanks for your review. Please find the rebased patch to latest HEAD.
Committed with minor (mostly cosmetic) alterations.
Thanks.
Regards,
Hari Babu
Fujitsu Australia
--
On 2014-08-31 16:03:30 -0400, Tom Lane wrote:
Another thought about this general topic:
Alvaro Herrera alvhe...@2ndquadrant.com writes:
...
Allowed actions on a RELKIND_PARTITION:
* CREATE INDEX .. ON PARTITION n ON TABLE xyz
...
Still To Be Designed
* Are
On Mon, Sep 1, 2014 at 4:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
The push into executor idea I was alluding to is that we might invent
plan constructs like a ModifyTable node that applies to a whole
inheritance^H^H^Hpartitioning tree and leaves the tuple routing to be
done at runtime.
On 2014-09-01 11:59:37 -0400, Tom Lane wrote:
Greg Stark st...@mit.edu writes:
On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Aside from costing planning time, most likely that would forever prevent
us from pushing some types of intelligence about partitioning into the
On 09/01/2014 06:59 PM, Tom Lane wrote:
Greg Stark st...@mit.edu writes:
On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Aside from costing planning time, most likely that would forever prevent
us from pushing some types of intelligence about partitioning into the
executor.
Hmm yes I am learning that the BG worker system isn't as helpful as I had
hoped due to the single database restriction.
As for a writing a frontend this might be the best solution.
A java frontend would be easy but pointless because the whole point here is
to provide a lightweight access method
On 08/30/2014 12:15 AM, Kevin Grittner wrote:
Heikki Linnakangas hlinnakan...@vmware.com wrote:
On 08/28/2014 12:03 AM, Kevin Grittner wrote:
Heikki Linnakangas hlinnakan...@vmware.com wrote:
I suggest adding a new hook to the ParseState struct, (p_rangevar_hook
?). The planner calls it
On 09/01/2014 05:52 PM, Andres Freund wrote:
On 2014-08-29 20:12:16 +0200, Hannu Krosing wrote:
It would need to replace plain tid (pagenr, tupnr) with triple of (partid,
pagenr, tupnr).
Cross-partition indexes are especially needed if we want to allow putting
UNIQUE constraints on
Stepan Rutz stepan.r...@gmx.de writes:
Attached is a very trivial patch as a basis for discussion that at least
makes \s (show history) work in psql on Macs. Macs uses libedit, which has a
libreadline interface.
Hm. The $64 question here is whether we can assume that history_get()
exists
Heikki Linnakangas hlinnakan...@vmware.com writes:
On 08/30/2014 12:15 AM, Kevin Grittner wrote:
If we were to go with the hooks as you propose, we would still need
to take the information from TriggerData and put it somewhere else
for the hook to reference.
Sure.
FWIW, I agree with Heikki
On Mon, Sep 1, 2014 at 10:39 AM, Alexey Klyukin al...@hintbits.com wrote:
On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas
hlinnakan...@vmware.com wrote:
Yeah, I think a certificate without CN should be supported. See also RFC
6125, section 4.1. Rules [for issuers of certificates]:
On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What is actually being proposed, AFAICS, is a one-shot fix for a bunch
of unfortunate choices. That might be worth doing, but let's not fool
ourselves about whether it's one-shot or not.
I'm glad to hear you think it *might*
2014-09-01 12:33 GMT+02:00 Jeevan Chalke jeevan.cha...@enterprisedb.com:
Hi Pavel,
Patch does look good to me. And found no issues as such.
However here are my optional suggestions:
1. Frankly, I did not like name of the function
row_to_json_pretty_choosy.
Something like
On 01/09/14 14:27, Joel Jacobson wrote:
On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule pavel.steh...@gmail.com wrote:
I agree with Andres - it is not a good for plpgsql and for plpgsql users.
The benefit must be significant for 90% of users.
...
Official implementation of plpgsql2 can be very
2014-09-01 20:23 GMT+02:00 Joel Jacobson j...@trustly.com:
On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane t...@sss.pgh.pa.us wrote:
What is actually being proposed, AFAICS, is a one-shot fix for a bunch
of unfortunate choices. That might be worth doing, but let's not fool
ourselves about
Joel Jacobson j...@trustly.com writes:
I see two possible approaches of a plpgsql2 project, both aiming to
require minimal/no changes of most existing best-practice plpgsql
code:
a) fork plpgsql code base and implement changes with as few lines of
code as possible, making it easier to
=?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= a...@nosys.es writes:
What I can add is that, if Postgres is to devote resources to a new
language, I would plan it with a broader scope. What would attract most
users? Would it bring non postgres users to Postgres? What could be one
of
On 01/09/14 20:42, Tom Lane wrote:
=?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= a...@nosys.es writes:
What I can add is that, if Postgres is to devote resources to a new
language, I would plan it with a broader scope. What would attract most
users? Would it bring non postgres users
2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa a...@nosys.es:
On 01/09/14 20:42, Tom Lane wrote:
=?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= a...@nosys.es writes:
What I can add is that, if Postgres is to devote resources to a new
language, I would plan it with a broader
On 01/09/14 01:42, Tom Lane wrote:
BTW, was there a reason for not noticing the case of exact match in
the search loop, and falling out early? As it stands the code will
reliably choose the leftmost match if there are multiple equal items
in the search array, but do we care about such cases?
On Mon, Sep 1, 2014 at 8:38 PM, Tom Lane t...@sss.pgh.pa.us wrote:
c) plpgsql and plpgsql2 are the same code base, with a small number
of places that act differently depending on the language version.
+1 to the idea
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To
Thanks Tom. This would help the poor mac-osx guys like me. I guess this is not
that important because no one runs a production server on OS-X.
Back patching to 9.3 won’t work as is, some minor conflict was there.
Anyway, I am sure the iteration used in encode_history and decode_history in
On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa a...@nosys.es wrote:
What I can add is that, if Postgres is to devote resources to a new
language, I would plan it with a broader scope. What would attract most
users? Would it bring non postgres users to Postgres? What could be one
On Sun, Aug 31, 2014 at 02:10:33PM -0400, Tom Lane wrote:
David G Johnston david.g.johns...@gmail.com writes:
Would it be proper to issue an additional top-level warning with the column
moved notification? Thus there would be NOTICE, NOTICE, WARNING in the
above example? Or, more
1 - 100 of 145 matches
Mail list logo
