Re: [HACKERS] Immediate standby promotion

On Mon, Sep 1, 2014 at 4:44 PM, Fujii Masao wrote: > On Mon, Sep 1, 2014 at 3:23 PM, Amit Kapila wrote: > > I think there is one downside as well for this proposal that > > apart from data loss, it can lead to uncommitted data occupying > > space in database which needs to be later cleaned by vac

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Thu, Aug 28, 2014 at 12:46 AM, Arthur Silva wrote: > > Em 26/08/2014 09:16, "Fujii Masao" escreveu: > > >> >> On Tue, Aug 19, 2014 at 6:37 PM, Rahila Syed >> wrote: >> > Hello, >> > Thank you for comments. >> > >> >>Could you tell me where the patch for "single block in one run" is? >> > Plea

Re: [HACKERS] [REVIEW] Re: Compression of full-page-writes

On Wed, Aug 27, 2014 at 11:52 PM, Robert Haas wrote: > On Tue, Aug 26, 2014 at 8:14 AM, Fujii Masao wrote: >> On Tue, Aug 19, 2014 at 6:37 PM, Rahila Syed wrote: >>> Hello, >>> Thank you for comments. >>> Could you tell me where the patch for "single block in one run" is? >>> Please find att

Re: [HACKERS] INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Thu, Aug 28, 2014 at 8:05 PM, Peter Geoghegan wrote: > I realized that I missed a few cases here. For one thing, the posted > patch fails to arrange for the UPDATE post-parse-analysis tree > representation to go through the rewriter stage (on the theory that > user-defined rules shouldn't be ab

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:06 AM, Joel Jacobson wrote: Given the needed diff between plpgsql and plpgsql2 for the changes I'm mostly interested in would probably be quite small, I'm in favour of Tom's suggestion of: c) plpgsql and plpgsql2 are the same code base, with a small number of places that act dif

Re: [HACKERS] PL/pgSQL 2

On Tue, Sep 2, 2014 at 5:46 AM, Craig Ringer wrote: > My point is that weeks can be spent just arguing about whether you > should have a variable-delimiter ($variable) or not, how syntax should > look, etc. Imagine how long it'd take to get a new language syntax > agreed upon? I would guess about

Re: [HACKERS] Patch for psql History Display on MacOSX

Noah Misch writes: > On Mon, Sep 01, 2014 at 10:22:57PM -0400, Tom Lane wrote: >> Also, as best I can tell, .psql_history files from older libedit versions >> are not forward-compatible to current libedit versions because of the >> failure of the decode_history() loop to reach all lines of the fil

Re: [HACKERS] Patch for psql History Display on MacOSX

On Mon, Sep 01, 2014 at 10:22:57PM -0400, Tom Lane wrote: > Noah Misch writes: > > On Mon, Sep 01, 2014 at 02:05:37PM -0400, Tom Lane wrote: > >> Functionally this seems like a clear win over what we had, especially > >> since it supports using the pager. I'm inclined to think we should > >> not

Re: [HACKERS] inherit support for foreign tables

Hello, I have a request with slight significance for the messages. > I'd like to address this by emitting the second message as shown below: > > INFO: analyzing "public.parent" > INFO: "parent": scanned 0 of 0 pages, containing 0 live rows and 0 dead > rows; 0 rows in sample, 0 estimated total

Re: [HACKERS] On partitioning

On 09/01/2014 04:03 AM, Tom Lane wrote: > I think one of the key design decisions we have to make is whether > partitions are all constrained to have exactly the same set of indexes. ... and a lot of that comes down to what use cases the partitioning is meant to handle, and what people are expect

Re: [HACKERS] On partitioning

On 09/01/2014 11:52 PM, Andres Freund wrote: > I personally think that implementing cross partition indexes has a low > enough cost/benefit ratio that I doubt it's wise to tackle it anytime > soon. UNIQUE constraints on partitioned tables (and thus foreign key constraints pointing to partitioned t

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 12:40 PM, Tom Lane wrote: > As a case in point, EDB have spent quite a few man-years on their Oracle > compatibility layer; and it's still not a terribly exact match, according > to my colleagues who have looked at it. So that is a tarbaby I don't > personally care to touch ... even

Re: [HACKERS] PL/pgSQL 2

Craig Ringer writes: > If someone came up with a convincing PL/SQL compatibility layer then > it'd be worth considering adopting - when it was ready. But of course, > anyone who does the work for that is quite likely to want to sell it to > cashed-up Oracle users looking to save a few hundred gran

Re: [HACKERS] orangutan seizes up during isolation-check

Noah Misch writes: > Buildfarm member orangutan has failed chronically on both of the branches for > which it still reports, HEAD and REL9_1_STABLE, for over two years. The > postmaster appears to jam during isolation-check. Dave, orangutan currently > has one such jammed postmaster for each bra

Re: [HACKERS] PL/pgSQL 2

On 14/09/02 12:24, Craig Ringer wrote: > On 09/02/2014 08:09 AM, Neil Tiffin wrote: (...) >> That should be enough alone to suggest postgreSQL start working on a modern, >> in core, fast, fully supported language. > > I couldn't disagree more. > > If we were to implement anything, it'd be PL/PS

Re: [HACKERS] PL/pgSQL 2

On 02/09/14 15:46, Craig Ringer wrote: was "is exactly why we need a new language" and that "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." But you haven't said HOW you propose to fix this one case. Unfortuna

Re: [HACKERS] Optimization for updating foreign tables in Postgres FDW

I confirmed performance gain accomplished by this patch. This patch makes update queries ~50x faster, and even hit-miss update is 3x faster than original. Of course benefit is only for queries whose qualifiers are enough simple so that they can be pushied down fully, but this improvement is remar

Re: [HACKERS] Concurrently option for reindexdb

On 09/02/2014 11:10 AM, Sawada Masahiko wrote: > The currently patch dose not hack catalog, just create new index > concurrently and > swap them. > So, It is supporting only UNIQUE index, I think. UNIQUE indexes, but not a UNIQUE constraint backed by a UNIQUE index, or a PRIMARY KEY constraint bac

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 11:42 AM, David Johnston wrote: > > ​Yet pl/pgsql does not have to use SPI-interface type calls to interact > with PostgreSQL at the SQL level... That's right. > ​I don't have an answer to your questions but the one I'm asking is > whether a particular language could hide all of th

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 11:19 PM, Joel Jacobson wrote: > On Mon, Sep 1, 2014 at 5:16 PM, Craig Ringer 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 b

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 11:12 PM, Craig Ringer wrote: > On 09/02/2014 09:40 AM, David G Johnston wrote: > > Random thought as I wrote that: how about considering how pl/pgsql > > functionality can be generalize so that it is a database API that > > another language can call? In that way the serve

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 05:46 AM, David G Johnston wrote: > The goal of adding PL/SQL would be to increase the user base of the project > and hopefully attract new blood to the development team in order to maximize > long-term survivability and increase the pace of innovation. We would be > unable to introd

Re: [HACKERS] add line number as prompt option to psql

On Tue, Sep 2, 2014 at 11:12 AM, Andres Freund wrote: > On 2014-08-31 12:06:31 +0900, Sawada Masahiko wrote: >> Thank you for review comment and improving the patch! >> I tested it. >> Your patch always increment line number even if there is no input line >> as follows. >> >> postgres[1]=# >> post

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 08:09 AM, Neil Tiffin wrote: > Now I could use other languages as was suggested upstream. Lets see, I use R > all the time, but R is not a first class language, not in core, and its slow. > Python 3 would be acceptable to me, but its untrusted. tcl I don’t know and > don’t want to

Re: [HACKERS] PL/pgSQL 2

On 09/02/2014 09:40 AM, David G Johnston wrote: > Random thought as I wrote that: how about considering how pl/pgsql > functionality can be generalize so that it is a database API that > another language can call? In that way the server would drive the core > functionality and the language would s

Re: [HACKERS] Concurrently option for reindexdb

On Mon, Sep 1, 2014 at 10:43 PM, Craig Ringer wrote: > 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

Re: [HACKERS] Patch for psql History Display on MacOSX

I've confirmed that the attached patches work as expected in both the oldest and newest readline and libedit versions available to me. Barring further objections, I plan to commit and back-patch these changes. regards, tom lane diff --git a/doc/src/sgml/ref/psql-ref.sgml b

Re: [HACKERS] Tips/advice for implementing integrated RESTful HTTP API

On Mon, Sep 1, 2014 at 7:00 PM, Craig Ringer wrote: > On 09/02/2014 12:50 AM, Dobes Vandermeer wrote: > > 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

Re: [HACKERS] add line number as prompt option to psql

On 2014-09-02 11:19:09 +0900, Michael Paquier wrote: > On Tue, Sep 2, 2014 at 11:12 AM, Andres Freund wrote: > > I've now used up a perfectly good glass of wine for this. > Red or white? From where? Useful tips for hacking in this area are > always useful. Hah ;). Nothing special, but I rather li

Re: [HACKERS] Patch for psql History Display on MacOSX

Noah Misch writes: > On Mon, Sep 01, 2014 at 02:05:37PM -0400, Tom Lane wrote: >> Functionally this seems like a clear win over what we had, especially >> since it supports using the pager. I'm inclined to think we should >> not only apply this change but back-patch it. > I've not used \s apart

Re: [HACKERS] add line number as prompt option to psql

On Tue, Sep 2, 2014 at 11:12 AM, Andres Freund wrote: > I've now used up a perfectly good glass of wine for this. Red or white? From where? Useful tips for hacking in this area are always useful. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes t

Re: [HACKERS] add line number as prompt option to psql

On 2014-08-31 12:06:31 +0900, Sawada Masahiko wrote: > Thank you for review comment and improving the patch! > I tested it. > Your patch always increment line number even if there is no input line > as follows. > > postgres[1]=# > postgres[2]=# select > postgres[3]-# , > postgres[4]-# from > postg

Re: [HACKERS] Tips/advice for implementing integrated RESTful HTTP API

On 09/02/2014 12:50 AM, Dobes Vandermeer wrote: > 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

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 9:07 PM, Andrew Dunstan [via PostgreSQL] < ml-node+s1045698n5817265...@n5.nabble.com> wrote: > > On 09/01/2014 08:09 PM, Neil Tiffin wrote: > > > > That should be enough alone to suggest postgreSQL start working on a > modern, in core, fast, fully supported language. Of cou

[HACKERS] orangutan seizes up during isolation-check

Buildfarm member orangutan has failed chronically on both of the branches for which it still reports, HEAD and REL9_1_STABLE, for over two years. The postmaster appears to jam during isolation-check. Dave, orangutan currently has one such jammed postmaster for each branch. Could you gather some

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 08:09 PM, Neil Tiffin wrote: On Sep 1, 2014, at 10:45 AM, Tom Lane 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. Well, one shot e

Re: [HACKERS] Patch for psql History Display on MacOSX

On Mon, Sep 01, 2014 at 02:05:37PM -0400, Tom Lane wrote: > Functionally this seems like a clear win over what we had, especially > since it supports using the pager. I'm inclined to think we should > not only apply this change but back-patch it. > > One thing worth thinking about: should we use

Re: [HACKERS] PL/pgSQL 2

On Sep 1, 2014, at 10:45 AM, Tom Lane 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. Well, one shot every 18 years is not so bad. I am only

Re: [HACKERS] PL/PgSQL: RAISE and the number of parameters

On 2014-08-12 13:23, I wrote: The compile-time raise parameter checking is a good move. 3 minor points: - I would suggest to avoid "continue" within a loop so that the code is simpler to understand, at least for me. I personally find the code easier to read with the continue. I've changed t

Re: [HACKERS] Patch for psql History Display on MacOSX

I wrote: >> Stepan Rutz writes: >>> Anyway, I am sure the iteration used in encode_history and decode_history >>> in input.c does not work on libedit. >> Yeah, I noticed your comment about that. That seems odd; a look at the >> Apple libedit sources suggests it should work. I was just about to

[HACKERS] Re: [BUGS] Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns

On Sat, Aug 30, 2014 at 07:32:26PM -0400, Bruce Momjian wrote: > On Wed, Aug 27, 2014 at 09:40:30PM -0400, Noah Misch wrote: > > > > 3. use the pg_dump binary-upgrade code when such cases happen > > > > +1. We have the convention that, while --binary-upgrade can inject catalog > > hacks, regular

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 23:46, David G Johnston wrote: Álvaro Hernández Tortosa wrote On 01/09/14 21:52, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa < aht@ > wrote: What I can add is that, if Postgres is to devote resources to a new language, I would plan it with

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 23:31, Marko Tiikkaja wrote: On 2014-09-01 11:11 PM, Álvaro Hernández Tortosa wrote: No, really: if there is a new version of a "language", which modifies the current syntax of plpgsql; if plpgsql is already very similar to PL/SQL: why not rather than coming up with a new synt

Re: [HACKERS] PL/pgSQL 2

Álvaro Hernández Tortosa wrote > On 01/09/14 21:52, Joel Jacobson wrote: >> On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa < > aht@ > > 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 attr

Re: [HACKERS] PL/pgSQL 2

On 2014-09-01 11:11 PM, Álvaro Hernández Tortosa wrote: No, really: if there is a new version of a "language", which modifies the current syntax of plpgsql; if plpgsql is already very similar to PL/SQL: why not rather than coming up with a new syntax use an already existing one? One that ma

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 21:52, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa 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 P

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 21:08, Pavel Stehule wrote: 2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa >: On 01/09/14 20:42, Tom Lane wrote: =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= mailto:a...@nosys.es>> writes: What I can add is that, if

Re: [HACKERS] Re: [BUGS] Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns

On Mon, Sep 1, 2014 at 04:06:58PM -0400, Tom Lane wrote: > Bruce Momjian writes: > > NOTICE: moving and merging column "c" with inherited definition > > DETAIL: user-specified column moved to the location of the inherited > > column > > Dept of nitpicking: errdetail messages are su

Re: [HACKERS] Patch for psql History Display on MacOSX

I wrote: > Stepan Rutz writes: >> Anyway, I am sure the iteration used in encode_history and decode_history in >> input.c does not work on libedit. > Yeah, I noticed your comment about that. That seems odd; a look at the > Apple libedit sources suggests it should work. I was just about to trac

Re: [HACKERS] Re: [BUGS] Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns

Bruce Momjian writes: > NOTICE: moving and merging column "c" with inherited definition > DETAIL: user-specified column moved to the location of the inherited > column Dept of nitpicking: errdetail messages are supposed to be complete sentences, properly capitalized and punctu

Re: [HACKERS] Patch for psql History Display on MacOSX

Stepan Rutz writes: > Anyway, I am sure the iteration used in encode_history and decode_history in > input.c does not work on libedit. Yeah, I noticed your comment about that. That seems odd; a look at the Apple libedit sources suggests it should work. I was just about to trace through the log

Re: [HACKERS] Re: [BUGS] Re: BUG #9555: pg_dump for tables with inheritance recreates the table with the wrong order of columns

On Sun, Aug 31, 2014 at 02:10:33PM -0400, Tom Lane wrote: > David G Johnston 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 generically, "columns reorde

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 8:34 PM, Álvaro Hernández Tortosa 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 of > the kil

Re: [HACKERS] Patch for psql History Display on MacOSX

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 in

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 8:38 PM, Tom Lane 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 make changes to your

Re: [HACKERS] Built-in binning functions

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?

Re: [HACKERS] PL/pgSQL 2

2014-09-01 20:58 GMT+02:00 Álvaro Hernández Tortosa : > > On 01/09/14 20:42, Tom Lane wrote: > >> =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= 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 woul

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 20:42, Tom Lane wrote: =?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= 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? Wh

Re: [HACKERS] PL/pgSQL 2

=?UTF-8?B?w4FsdmFybyBIZXJuw6FuZGV6IFRvcnRvc2E=?= 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 the killer

Re: [HACKERS] PL/pgSQL 2

Joel Jacobson 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 understand the chan

Re: [HACKERS] PL/pgSQL 2

2014-09-01 20:23 GMT+02:00 Joel Jacobson : > On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane 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. > >

Re: [HACKERS] PL/pgSQL 2

On 01/09/14 14:27, Joel Jacobson wrote: 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 sig

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

2014-09-01 12:33 GMT+02:00 Jeevan Chalke : > 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" se

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 5:45 PM, Tom Lane 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* be worth doing. A

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

On Mon, Sep 1, 2014 at 10:39 AM, Alexey Klyukin wrote: > On Fri, Aug 29, 2014 at 11:22 AM, Heikki Linnakangas > wrote: >> Yeah, I think a certificate without CN should be supported. See also RFC >> 6125, section 4.1. "Rules" [for issuers of certificates]: >> >>>5. Even though many deployed

Re: [HACKERS] delta relations in AFTER triggers

Heikki Linnakangas 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 this point.

Re: [HACKERS] Patch for psql History Display on MacOSX

Stepan Rutz 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 and works compati

Re: [HACKERS] On partitioning

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

Re: [HACKERS] delta relations in AFTER triggers

On 08/30/2014 12:15 AM, Kevin Grittner wrote: Heikki Linnakangas wrote: On 08/28/2014 12:03 AM, Kevin Grittner wrote: Heikki Linnakangas wrote: I suggest adding a new hook to the ParseState struct, (p_rangevar_hook ?). The planner calls it whenever it sees a reference to a table, and the hoo

Re: [HACKERS] Tips/advice for implementing integrated RESTful HTTP API

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 t

Re: [HACKERS] On partitioning

On 09/01/2014 06:59 PM, Tom Lane wrote: Greg Stark writes: On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane 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 cal

Re: [HACKERS] On partitioning

On 2014-09-01 11:59:37 -0400, Tom Lane wrote: > Greg Stark writes: > > On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane wrote: > >> Aside from costing planning time, most likely that would forever prevent > >> us from pushing some types of intelligence about partitioning into the > >> executor. > > > H

Re: [HACKERS] On partitioning

On Mon, Sep 1, 2014 at 4:59 PM, Tom Lane 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. You're not going t

Re: [HACKERS] On partitioning

On 2014-08-31 16:03:30 -0400, Tom Lane wrote: > Another thought about this general topic: > > Alvaro Herrera writes: > > ... > > Allowed actions on a RELKIND_PARTITION: > > * CREATE INDEX .. ON PARTITION ON TABLE > > ... > > Still To Be Designed > > > > * Are indexes/constr

Re: [HACKERS] [BUGS] BUG #9652: inet types don't support min/max

On Fri, Aug 29, 2014 at 12:39 PM, Tom Lane wrote: > Haribabu Kommi 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 -- Sent via pgsql-hackers mailing list (pgs

Re: [HACKERS] On partitioning

Greg Stark writes: > On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane 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 i

Re: [HACKERS] On partitioning

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

Re: [HACKERS] On partitioning

On Sun, Aug 31, 2014 at 9:03 PM, Tom Lane 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 which were created o

Re: [HACKERS] PL/pgSQL 2

Andres Freund writes: > 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

[HACKERS] Patch for psql History Display on MacOSX

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 libr

Re: [HACKERS] PL/pgSQL 2

Joel Jacobson-2 wrote > On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer < > craig@ > > 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 clums

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 5:16 PM, Craig Ringer 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. >> >> I guess

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 4:41 PM, Andres Freund 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 after the set of

Re: [HACKERS] psql \watch versus \timing

Michael Paquier 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 to the behavior in HE

Re: [HACKERS] PL/pgSQL 2

2014-09-01 16:41 GMT+02:00 Joel Jacobson : > On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer > 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. > A

Re: [HACKERS] PL/pgSQL 2

2014-09-01 16:39 GMT+02:00 Hannu Krosing : > 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 th

Re: [HACKERS] PL/pgSQL 2

On 09/01/2014 05:41 PM, Joel Jacobson wrote: On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer 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. We could certainly i

Re: [HACKERS] PL/pgSQL 2

On 2014-09-01 16:29:18 +0200, Joel Jacobson wrote: > On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund wrote: > > 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 wil

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 4:26 PM, Craig Ringer 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, can easily be fix

Re: [HACKERS] PL/pgSQL 2

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. > Y

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

+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 wrote: > On 09/01/2014 05:04 PM, Joel Jacobson wrote: >> From the top of my head, these are Things I pe

Re: [HACKERS] PL/pgSQL 2

On Mon, Sep 1, 2014 at 3:25 PM, Andres Freund wrote: > 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 plpgs

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

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 specifyin

Re: [HACKERS] PL/pgSQL 2

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

Re: [HACKERS] PL/pgSQL 2

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 forma

Re: [HACKERS] PL/pgSQL 2

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 bet

Re: [HACKERS] PL/pgSQL 2

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

  1   2   >