Re: [HACKERS] PL/pgSQL 2

2014-09-01 16:01 GMT+02:00 Craig Ringer : > 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 > > co

Re: [HACKERS] PL/pgSQL 2

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 mu

Re: [HACKERS] PL/pgSQL 2

2014-09-01 15:52 GMT+02:00 Craig Ringer : > 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. > >

Re: [HACKERS] PL/pgSQL 2

2014-09-01 15:12 GMT+02:00 Marko Tiikkaja : > On 9/1/14 2:53 PM, Pavel Stehule wrote: > >> 2014-09-01 14:27 GMT+02:00 Joel Jacobson : >> >> On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule >>> wrote: >>> I agree with Andres - it is not a good for plpgsql and for plpgsql users. The be

Re: [HACKERS] ALTER SYSTEM RESET?

On Mon, Sep 1, 2014 at 3:57 PM, Fujii Masao wrote: > > On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila wrote: > > On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao wrote: > >> The patch looks good to me. One minor comment is; probably you need to > >> update the tab-completion code. > > > > Thanks for

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

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 thou

Re: [HACKERS] Concurrently option for reindexdb

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

Re: [HACKERS] psql \watch versus \timing

On Fri, Aug 29, 2014 at 6:33 PM, Heikki Linnakangas wrote: > On 08/28/2014 02:46 PM, Fujii Masao wrote: >> >> On Tue, Aug 26, 2014 at 4:55 AM, Heikki Linnakangas >> wrote: >>> >>> On 08/25/2014 10:48 PM, Heikki Linnakangas wrote: Actually, perhaps it would be better to just copy-paste P

Re: [HACKERS] PL/pgSQL 2

On 2014-09-01 15:19:41 +0200, Joel Jacobson wrote: > On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule 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

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 2:53 PM, Pavel Stehule 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, but that's a non-is

Re: [HACKERS] PL/pgSQL 2

On 9/1/14 2:53 PM, Pavel Stehule wrote: 2014-09-01 14:27 GMT+02:00 Joel Jacobson : On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule 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

Re: [HACKERS] Better support of exported snapshots with pg_dump

On 2014-09-01 21:54:24 +0900, Michael Paquier wrote: > On Mon, Sep 1, 2014 at 6:30 PM, Andres Freund 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 mind is only for

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] Better support of exported snapshots with pg_dump

On Mon, Sep 1, 2014 at 6:30 PM, Andres Freund 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: >> >> Thanks. It

Re: [HACKERS] PL/pgSQL 2

2014-09-01 14:27 GMT+02:00 Joel Jacobson : > On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule > 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 a

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 1:30 PM, Pavel Stehule 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 not to do. Do you

Re: [HACKERS] LIMIT for UPDATE and DELETE

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

Re: [HACKERS] pg_receivexlog and replication slots

On 2014-09-01 20:58:29 +0900, Michael Paquier wrote: > On Sun, Aug 31, 2014 at 10:45 PM, Magnus Hagander 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 sh

Re: [HACKERS] pg_receivexlog and replication slots

On Sun, Aug 31, 2014 at 10:45 PM, Magnus Hagander 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 > replication slots, ri

Re: [HACKERS] alter user set local_preload_libraries.

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 c

Re: [HACKERS] Adding 'crosstab' variants returning refcursor?

Hi 2014-09-01 13:08 GMT+02:00 Craig Ringer : > 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 > > Consuming th

Re: [HACKERS] PL/pgSQL 2

2014-09-01 13:30 GMT+02:00 Joel Jacobson : > On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund > 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 vers

Re: [HACKERS] PL/pgSQL 2

Hi 2014-09-01 11:04 GMT+02:00 Joel Jacobson : > 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

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 12:55 PM, Andres Freund 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 with a completely

[HACKERS] postgres_fdw behaves oddly

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

Re: [HACKERS] Immediate standby promotion

On Mon, Sep 1, 2014 at 3:23 PM, Amit Kapila wrote: > On Thu, Aug 14, 2014 at 1:49 PM, Fujii Masao 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 i

Re: [HACKERS] Concurrently option for reindexdb

On Wed, Aug 27, 2014 at 11:02 AM, Michael Paquier wrote: > On Tue, Aug 26, 2014 at 5:12 PM, Andres Freund 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 have today. > Well, if somebody has

[HACKERS] Adding 'crosstab' variants returning refcursor?

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 n

Re: [HACKERS] PL/pgSQL 2

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 the

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

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 function

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 12:32 PM, Hannu Krosing 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 is easier sa

Re: [HACKERS] Re: proposal: ignore null fields in not relation type composite type based constructors

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 t

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] ALTER SYSTEM RESET?

On Sat, Aug 30, 2014 at 12:27 PM, Amit Kapila wrote: > On Wed, Aug 27, 2014 at 7:16 PM, Fujii Masao 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 the patch to support > tab-completion.

Re: [HACKERS] PL/pgSQL 2

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 > >LOC

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 11:24 AM, Andres Freund 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 concern, and is als

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] Make LWLockAcquireCommon() inline?

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 do

Re: [HACKERS] PL/pgSQL 2

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 pos

Re: [Fwd: Re: [HACKERS] proposal: new long psql parameter --on-error-stop]

On Thu, Aug 28, 2014 at 9:34 PM, Pavel Stehule wrote: > > > > 2014-08-28 14:22 GMT+02:00 Fujii Masao : > >> On Thu, Aug 28, 2014 at 5:48 AM, Pavel Stehule >> wrote: >> > comments? >> >> +fprintf(output, _(" ECHO control what input is >> written to standard output [all, queries]

Re: [HACKERS] Better support of exported snapshots with pg_dump

Hi, On 2014-09-01 10:25:58 +0200, Bernd Helmle wrote: > --On 1. September 2014 17:00:32 +0900 Michael Paquier > 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_snapsh

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/PgSQL: EXIT USING ROLLBACK

On Sat, Jul 26, 2014 at 8:39 PM, Tom Lane 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 main difference

[HACKERS] PL/pgSQL 2

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, t

Re: [HACKERS] implement subject alternative names support for SSL connections

On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas 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 11:53

Re: [HACKERS] Better support of exported snapshots with pg_dump

--On 1. September 2014 17:00:32 +0900 Michael Paquier 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 within it). I imagine that

Re: [HACKERS] What in the world is happening with castoroides and protosciurus?

On Sat, Aug 30, 2014 at 11:32 PM, Noah Misch 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 wrote: >> > For the last month or so, these two buildfarm animals (which I believe are >> > the same physical machine) have been erraticall

[HACKERS] Better support of exported snapshots with pg_dump

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 dat

<    1   2