Re: [HACKERS] [POC] FETCH limited by bytes.

I applied this patch to REL9_4_STABLE, and I was able to connect to a foreign database (redshift, actually). the basic outline of the test is below, names changed to protect my employment. create extension if not exists postgres_fdw; create server redshift_server foreign data wrapper

Re: [HACKERS] GRANT USAGE on FOREIGN SERVER exposes passwords

It is far from central to this conversation, but I can confirm that RedShift currently only supports user+pass combinations. It's likely that each node has a pg_hba.conf, but the customer is not given credentials to ssh to the individual nodes. On Thu, Feb 5, 2015 at 10:48 AM, Stephen Frost

Re: [HACKERS] Commit fest 2015-12 enters money time

What is required to get the New Patch superpower? I'm also in need of it. On Mon, Feb 16, 2015 at 6:59 PM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: On Tue, Feb 17, 2015 at 8:50 AM, Kouhei Kaigai kai...@ak.jp.nec.com wrote: I couldn't find operation to add new entry on the current CF.

[HACKERS] dblink: add polymorphic functions.

In the course of writing a small side project which hopefully will make its way onto pgxn soon, I was writing functions that had a polymorphic result set. create function foo( p_row_type anyelement, p_param1 ...) returns setof anyelement Inside that function would be multiple calls to dblink()

Re: [HACKERS] dblink: add polymorphic functions.

that to Magnus already. On Thu, Feb 19, 2015 at 11:00 PM, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Feb 20, 2015 at 7:06 AM, Corey Huinker corey.huin...@gmail.com wrote: Proposed patch attached. At quick glance, this patch lacks two things: - regression test coverage

Re: [HACKERS] [POC] FETCH limited by bytes.

Last year I was working on a patch to postgres_fdw where the fetch_size could be set at the table level and the server level. I was able to get the settings parsed and they would show up in pg_foreign_table and pg_foreign_servers. Unfortunately, I'm not very familiar with how foreign data

Re: [HACKERS] [POC] FETCH limited by bytes.

statement is defenitly ugly, especially the overhead argument is prohibitive even for me:( Thanks to Kyotaro and Bruce Momjian for their help. Not at all. regardes, At Wed, 4 Feb 2015 18:06:02 -0500, Corey Huinker corey.huin...@gmail.com wrote in CADkLM=eTpKYX5VOfjLr0VvfXhEZbC2UeakN

Re: [HACKERS] Patch: raise default for max_wal_segments to 1GB

Naive question: would it be /possible/ to change configuration to accept percentages, and have a percent mean of existing RAM at startup time? I ask because most of the tuning guidelines I see suggest setting memory parameters as a % of RAM available. On Tue, Mar 3, 2015 at 1:29 PM, Heikki

Re: [HACKERS] Patch: raise default for max_wal_segments to 1GB

No intention to hijack. Dropping issue for now. On Tue, Mar 3, 2015 at 2:05 PM, Josh Berkus j...@agliodbs.com wrote: On 03/03/2015 10:58 AM, Corey Huinker wrote: Naive question: would it be /possible/ to change configuration to accept percentages, and have a percent mean of existing RAM

Re: [HACKERS] dblink: add polymorphic functions.

Changes in this patch: - added polymorphic versions of dblink_fetch() - upped dblink version # to 1.2 because of new functions - migration 1.1 - 1.2 - DocBook changes for dblink(), dblink_get_result(), dblink_fetch() On Sun, Feb 22, 2015 at 11:38 PM, Corey Huinker corey.huin...@gmail.com wrote

Re: [HACKERS] dblink: add polymorphic functions.

, Feb 23, 2015 at 12:03 PM, Corey Huinker corey.huin...@gmail.com wrote: + ERROR: could not stat file /home/ubuntu/src/postgres/contrib/dblink/tmp_check/install/usr/local/pgsql/share/extension/dblink--1.2.sql: No such file or directory Didn't you forget to add dblink--1.2.sql to DATA

Re: [HACKERS] dblink: add polymorphic functions.

to happen for new files to be seen by the regression test harness? On Fri, Feb 20, 2015 at 1:14 AM, Michael Paquier michael.paqu...@gmail.com wrote: On Fri, Feb 20, 2015 at 2:50 PM, Corey Huinker corey.huin...@gmail.com wrote: Thanks - completely new to this process, so I'm going to need walking

Re: [HACKERS] dblink: add polymorphic functions.

nevermind. Found it. On Sun, Feb 22, 2015 at 11:18 PM, Corey Huinker corey.huin...@gmail.com wrote: Yes, that was it, I discovered it myself and should have posted a nevermind. Now I'm slogging through figuring out where to find elog() messages from the temporary server. It's slow, but it's

Re: [HACKERS] Partitioning WIP patch (was: Partitioning: issues/ideas)

I think it's confusing to use BETWEEN to mean [low,high) when it already means [low,high] in WHERE clauses. Why not leverage range notation instead? CREATE TABLE parent_monthly_x_201401 PARTITION OF parent_monthly_x FOR VALUES IN RANGE '[2014-04-01,2014-05-01)' IN RANGE could easily be

Re: [HACKERS] proposal: condition blocks in psql

I was just musing about this today, and was afraid that no one else would want it! This would be useful to me in the following use cases which I have right now: 1. I have a SQL script that invokes \COPY into a temporary table or some similar thing, preventing most of my logic from being pushed

Re: [HACKERS] proposal: condition blocks in psql

I implemented \foreach five years ago, and this is not simple to implement statement - so don't propose it. I wouldn't to inject full scripting language to psql. Then it is better to use bash, perl, python. But well designed conditional statements needs only few lines for implementation,

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 3:52 PM, Merlin Moncure mmonc...@gmail.com wrote: On Mon, Jul 6, 2015 at 11:13 AM, Corey Huinker corey.huin...@gmail.com wrote: On Mon, Jul 6, 2015 at 11:33 AM, Merlin Moncure mmonc...@gmail.com wrote: On Mon, Jul 6, 2015 at 9:52 AM, Joe Conway m...@joeconway.com

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 11:33 AM, Merlin Moncure mmonc...@gmail.com wrote: On Mon, Jul 6, 2015 at 9:52 AM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 07:37 AM, Merlin Moncure wrote: yup, and at least one case now fails where

Re: [HACKERS] dblink: add polymorphic functions.

On Sun, Jul 5, 2015 at 9:00 PM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/05/2015 12:25 PM, Joe Conway wrote: On 02/22/2015 10:26 PM, Corey Huinker wrote: Changes in this patch: - added polymorphic versions of dblink_fetch() - upped dblink

Re: [HACKERS] dblink: add polymorphic functions.

On Mon, Jul 6, 2015 at 10:08 AM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/06/2015 12:39 AM, Michael Paquier wrote: Yeah, particularly the use of first_optarg makes things harder to follow in the code with this patch. A C wrapper has the

Re: [HACKERS] Declarative partitioning

On Tue, Aug 18, 2015 at 6:30 AM, Amit Langote langote_amit...@lab.ntt.co.jp wrote: Hi, I would like propose $SUBJECT for this development cycle. Attached is a WIP patch that implements most if not all of what's described below. Some yet unaddressed parts are mentioned below, too. I'll add

Re: [HACKERS] Declarative partitioning

It seems the way of specifying per-partition definition/constraint, especially for range partitioning, would have a number of interesting alternatives. By the way, the [USING opclass_name] bit is just a way of telling that a particular key column has user-defined notion of ordering in case

Re: [HACKERS] Declarative partitioning

My experiences with Oracle's hash function were generally not good - there's a reason many hash algorithms exist. If/when we do hash partitioning in Postgres I'd like to see the hash function be user-definable. +1 In my experience, hash partitioning had one use: When you had run out of

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 29, 2015 at 12:14 PM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/29/2015 08:56 AM, Corey Huinker wrote: On Wed, Jul 29, 2015 at 10:48 AM, Tom Lane t...@sss.pgh.pa.us Not sure why inserting a variable name is so much better than

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 29, 2015 at 10:48 AM, Tom Lane t...@sss.pgh.pa.us wrote: Corey Huinker corey.huin...@gmail.com writes: On Wed, Jul 29, 2015 at 3:48 AM, Heikki Linnakangas hlinn...@iki.fi wrote: Let's pursue the CAST(srf() AS row_rtype) syntax that Joe suggested upthread ( http

Re: [HACKERS] dblink: add polymorphic functions.

Ok, gotcha. So Tom's nearby comment about allowing the p_rowtype%TYPE syntax to be used in the CAST is spot on (as usual). In other words, to get a complete solution for you we would need to make both things work, so you could do this inside plpgsql: select * from cast(dblink(connstr,

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 29, 2015 at 3:48 AM, Heikki Linnakangas hlinn...@iki.fi wrote: On 07/18/2015 01:32 AM, Corey Huinker wrote: So this patch would result in less C code while still adding 3 new functions. Can anyone think of why that wouldn't be the best way to go? Let's pursue the CAST(srf

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 12:21 PM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2015 08:51 AM, Corey Huinker wrote: Questions: Would moving rowtype to the first parameter resolve the parameter ambiguity issue? Not for the existing functions

Re: [HACKERS] First Aggregate Funtion?

On Mon, Jul 20, 2015 at 11:06 AM, Paul A Jungwirth p...@illuminatedcomputing.com wrote: The above implementation of first aggregate returns the first non-NULL item value. I'm curious what advantages this approach has over these FIRST/LAST functions from the Wiki?:

Re: [HACKERS] Using quicksort for every external sort run

icksort with spillover" > > idea...although not quite how I anticipated it would. It seems like > > I've reached a good point to get some feedback. > > Corey Huinker has once again assisted me with this work, by doing some > benchmarking on an AWS instance of his: > >

Re: [HACKERS] Foreign Data Wrapper

On Fri, Nov 13, 2015 at 1:46 PM, Big Mike wrote: > Writing a Foreign Data Wrapper and interested in isolating the WHERE > clause to speed up the access of an indexed file on my filesystem. I'm > attempting to understand the inner workings of how the data is retrieved so >

Re: [HACKERS] Getting sorted data from foreign server for merge join

On Fri, Nov 6, 2015 at 11:32 AM, Robert Haas wrote: > On Thu, Nov 5, 2015 at 11:54 PM, Ashutosh Bapat > wrote: > > Hi All, > > PFA patch to get data sorted from the foreign server (postgres_fdw) > > according to the pathkeys useful for

Re: [HACKERS] dblink: add polymorphic functions.

On Wed, Jul 8, 2015 at 11:29 AM, Merlin Moncure mmonc...@gmail.com wrote: On Wed, Jul 8, 2015 at 10:12 AM, Joe Conway m...@joeconway.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2015 10:22 PM, Michael Paquier wrote: On Mon, Jul 6, 2015 at 11:52 PM, Joe Conway

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Tue, Nov 17, 2015 at 7:28 PM, Michael Paquier wrote: > On Wed, Nov 18, 2015 at 8:50 AM, Peter Geoghegan wrote: > > I seem to be able to produce these sorting patches at a much greater > > rate than they can be committed, in part because Robert is the only > > one

Re: [HACKERS] [POC] FETCH limited by bytes.

On Wed, Sep 2, 2015 at 9:08 AM, Andres Freund <and...@anarazel.de> wrote: > On 2015-02-27 13:50:22 -0500, Corey Huinker wrote: > > +static DefElem* > > +get_option(List *options, char *optname) > > +{ > > + ListCell *lc; &g

Re: [HACKERS] proposal: function parse_ident

On Tue, Sep 8, 2015 at 8:57 AM, Pavel Stehule wrote: > > > 2015-09-08 14:06 GMT+02:00 Robert Haas : > >> On Fri, Sep 4, 2015 at 12:24 AM, Pavel Stehule >> wrote: >> > The alghoritm for parsing identifiers is same - the

Re: [HACKERS] No Issue Tracker - Say it Ain't So!

> > > And they'd sure love to be in charge of our code repo. >> > > Mh - i'm not a native speaker. I didn't understand this line. > > Tom was saying that the JIRA/Atlassian people would happily volunteer to host our code repository for no cost (in money) to us. The implication being that they have

Re: [HACKERS] [POC] FETCH limited by bytes.

able->options, "fetch_size"); > + .. > + fpinfo->fetch_size = strtod(defGetString... > > Also it is doable in postgresGetForeignPlan and doing there > removes redundant copy of fetch_size from PgFdwRelation to > PgFdwScanState but theoretical basis wou

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Fri, Dec 11, 2015 at 12:13 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Wed, Dec 9, 2015 at 8:16 PM, Peter Geoghegan <p...@heroku.com> wrote: > > On Tue, Nov 17, 2015 at 7:33 PM, Corey Huinker <corey.huin...@gmail.com> > wrote: > >> I'm w

Re: [HACKERS] Disabling an index temporarily

On Sun, Dec 13, 2015 at 11:03 PM, Tom Lane wrote: > Jeff Janes writes: > > Not to hijack the thread even further in the wrong direction, but I > > think what Corey really wants here is to stop maintaining the index at > > retail while preserving the

Re: [HACKERS] Disabling an index temporarily

On Sun, Dec 13, 2015 at 10:23 PM, Bill Moran <wmo...@potentialtech.com> wrote: > On Sun, 13 Dec 2015 22:15:31 -0500 > Corey Huinker <corey.huin...@gmail.com> wrote: > > > ALTER TABLE foo DISABLE [NONUNIQUE] INDEXES > > -- same, but joining to pg_class and possib

Re: [HACKERS] Disabling an index temporarily

On Sun, Dec 13, 2015 at 1:33 AM, Oleg Bartunov wrote: > > On Sun, Dec 13, 2015 at 1:16 AM, Jaime Casanova < > jaime.casan...@2ndquadrant.com> wrote: > >> indexrelid = 'indexname'::regclass; > > > This works, but might bloat system catalog. > > +1 for the functionality. +1

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Fri, Dec 11, 2015 at 5:35 PM, Peter Geoghegan <p...@heroku.com> wrote: > On Fri, Dec 11, 2015 at 2:26 PM, Corey Huinker <corey.huin...@gmail.com> > wrote: > > Sure, the machine we called "ninefivealpha", which incidentally, failed > to > > find a si

Re: [HACKERS] Should TIDs be typbyval = FLOAT8PASSBYVAL to speed up CREATE INDEX CONCURRENTLY?

On Wed, Dec 16, 2015 at 4:24 PM, Peter Geoghegan wrote: > On Wed, Dec 16, 2015 at 12:28 PM, Robert Haas > wrote: > >> I seem to be able to produce these sorting patches at a much greater > >> rate than they can be committed, in part because Robert is the

Re: [HACKERS] [POC] FETCH limited by bytes.

> > >> I believe it won't be needed as a regression test but DEBUGn >> messages could be usable to see "what was sent to the remote >> side". It can be shown to the console so easily done in >> regression test. See the deocumentation for client_min_messages >> for details. (It could receive far

Re: [HACKERS] [POC] FETCH limited by bytes.

On Wed, Dec 23, 2015 at 3:08 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: > On 12/23/15 12:15 PM, Corey Huinker wrote: > >> That's fair. I'm still at a loss for how to show that the fetch size was >> respected by the remote server, suggestions welcome! >&g

Re: [HACKERS] [POC] FETCH limited by bytes.

On Wed, Dec 23, 2015 at 8:43 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Sep 21, 2015 at 1:52 PM, Corey Huinker <corey.huin...@gmail.com> > wrote: > > Attached is the patch / diff against current master. > > I have moved this patch to

Re: [HACKERS] [POC] FETCH limited by bytes.

On Fri, Dec 25, 2015 at 12:31 AM, Kyotaro HORIGUCHI < horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > > At Thu, 24 Dec 2015 18:31:42 -0500, Corey Huinker <corey.huin...@gmail.com> > wrote in

Re: [HACKERS] [POC] FETCH limited by bytes.

On Sat, Dec 26, 2015 at 6:16 AM, Vladimir Sitnikov < sitnikov.vladi...@gmail.com> wrote: > >Have you got numbers showing any actual performance win for postgres_fdw? > > For JDBC purposes, it would be nice to have an ability of asking > backend "to stop fetching if produced more than X MiB of

Re: [HACKERS] custom function for converting human readable sizes to bytes

> > What about pg_size_unpretty()? > I was going to suggest pg_size_ugly(), but unpretty does emphasize the inverse (rather than opposite) nature of the function.

Re: [HACKERS] custom function for converting human readable sizes to bytes

On Sun, Nov 22, 2015 at 11:24 PM, Pavel Stehule <pavel.steh...@gmail.com> wrote: > > > 2015-11-22 23:54 GMT+01:00 Corey Huinker <corey.huin...@gmail.com>: > >> What about pg_size_unpretty()? >>> >> I was going to suggest pg_size_ugly(), but unpret

Re: [HACKERS] onlyvalue aggregate (was: First Aggregate Funtion?)

On Fri, Nov 20, 2015 at 10:54 PM, Marko Tiikkaja wrote: > Hi Dean, > > Here's v2 of the patch. How's this look? > > > .m > > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: >

[HACKERS] Let file_fdw access COPY FROM PROGRAM

A while back, there was a push to make COPY gzip-aware. That didn't happen, but COPY FROM PROGRAM did, and it scratches the same itch. I have a similar need, but with file_fdw foreign tables. I have .csv.gz files downloaded to the server, but those CSVs have 100+ columns in them, and in this case

Re: [HACKERS] Let file_fdw access COPY FROM PROGRAM

On Fri, Jun 3, 2016 at 1:06 AM, Craig Ringer <cr...@2ndquadrant.com> wrote: > On 3 June 2016 at 04:48, Corey Huinker <corey.huin...@gmail.com> wrote: > >> A while back, there was a push to make COPY gzip-aware. That didn't >> happen, but COPY FROM PROGRAM did,

Re: [HACKERS] JSON[B] arrays are second-class citizens

On Tue, May 31, 2016 at 5:06 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, May 31, 2016 at 4:34 PM, David Fetter wrote: > >> Folks, >> >> While querying some JSONB blobs at work in preparation for a massive >> rework of the data infrastructure, I ran into

Re: [HACKERS] Allow COPY to use parameters

> > > For the following pretend that "STRING" has the same behavior as the > "format(...)" function. > > EXECUTE STRING('COPY %I TO %L', 'testtable', 'testfile.txt');​ > +1 We should make string sanitization easy so that people use it by default. In the mean time, if you're just using psql, the

Re: [HACKERS] Odd behavior with domains

On Thu, Jun 23, 2016 at 10:16 PM, Joshua D. Drake wrote: > Hey, > > So this came across my twitter feed: > > https://pbs.twimg.com/media/ClqIJtmXEAA5IGt.png > > I have verified the oddness with a newer version: > > psql -U postgres > psql (9.5.3) > Type "help" for help. >

Re: [HACKERS] Declarative partitioning

> > > If we have a CREATE statement for each partition, how do we generalize > that to partitions at different levels? For example, if we use something > like the following to create a partition of parent_name: > > CREATE PARTITION partition_name OF parent_name FOR VALUES ... > WITH ...

Re: [HACKERS] proposal: schema PL session variables

On Tue, Feb 9, 2016 at 2:55 PM, David G. Johnston < david.g.johns...@gmail.com> wrote: > On Tue, Feb 9, 2016 at 11:32 AM, Corey Huinker <corey.huin...@gmail.com> > wrote: > >> >> Oh, and I suggest we call them SESSION variables rather than SCHEMA >> varia

Re: [HACKERS] proposal: schema PL session variables

On Tue, Feb 9, 2016 at 9:58 AM, Pavel Stehule wrote: > > > 2016-02-09 15:32 GMT+01:00 Marko Tiikkaja : > >> On 08/02/16 14:16, Pavel Stehule wrote: >> >>> 2016-02-08 13:53 GMT+01:00 Marko Tiikkaja : >>> Yeah, and that's exactly what

Re: [HACKERS] enable parallel query by default?

> > I think that's an argument to enable it till at least beta1. Let's >> change the default, and add an item to the open items list to reconsider >> then. >> >> > +1 during the beta, +0.95 for default thereafter. I think that most databases in the past have defaulted to single-core unless

Re: [HACKERS] [POC] FETCH limited by bytes.

> > > Looks pretty good. You seem to have added a blank line at the end of > postgres_fdw.c, which should be stripped back out. > Done. > > > I'm not too keen on having *no* new regression tests, but defer to your > > judgement. > > So... I'm not *opposed* to regression tests. I just don't

Re: [HACKERS] Re: Add generate_series(date, date) and generate_series(date, date, integer)

Doh, I left that comment to myself in there. :) The corresponding structs in timestamp.c and int.c have no comment, so suggestions of what should be there are welcome. In the interim I put in this: /* state for generate_series_date(date,date,[step]) */ Extra linefeed after struct removed. Do

Re: [HACKERS] Re: Add generate_series(date, date) and generate_series(date, date, integer)

> > > > Do you have any insight as to why the documentation test failed? > > > > In the mean time, here's the updated patch. > > I didn't pass the docs on account of the wonky comment since I consider > code comments to be part of the docs. The sgml docs build fine and look > good to me. > > Ah,

Re: [HACKERS] [POC] FETCH limited by bytes.

> > > postgres_fdw.c:2642:16: error: use of undeclared identifier 'server' > foreach(lc, server->options) > Odd. Compiled for me. Maybe I messed up the diff. Will get back to you on that with the tests suggested. > ^ >

Re: [HACKERS] [POC] FETCH limited by bytes.

> > > I don't see how. There really is no declaration in there for a > variable called server. > Absolutely correct. My only guess is that it was from failing to make clean after a checkout/re-checkout. A good reason to have even boring regression tests. Regression tests added. diff --git

Re: [HACKERS] psql metaqueries with \gexec

> > In the mean time, update patch attached. > > Really attached this time. diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 9750a5b..5ca769f 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -849,6 +849,13 @@ exec_command(const char *cmd, status

Re: [HACKERS] psql metaqueries with \gexec

On Mon, Feb 22, 2016 at 11:30 AM, Corey Huinker <corey.huin...@gmail.com> wrote: > On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite <dan...@manitou-mail.org> > wrote: > >> Corey Huinker wrote: >> >> > ...and query text visibility, and resul

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

> > > > > Given that counterexample, I think we not only shouldn't back-patch such > a > > change but should reject it altogether. > > Ouch, good point. The overflows are a different problem that we had > better address though (still on my own TODO list)... > So I should remove the bounds

Re: [HACKERS] Declarative partitioning

> > Hm, I see. How about multi-column keys? Do we care enough about that use > case? I don't see a nice-enough-looking range literal for such keys. > Consider for instance, > > With the partitioned table defined as: > > CREATE TABLE foo(c1 char(2), c2 char(2)) PARTITION BY RANGE (c1, c2); >

Re: [HACKERS] psql metaqueries with \gexec

On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite <dan...@manitou-mail.org> wrote: > Corey Huinker wrote: > > > ...and query text visibility, and result visibility, and error handling, > > etc. In this case, we're leveraging the psql environment we'd already se

format() changes discussion (was: Re: [HACKERS] psql metaqueries with \gexec)

> > (One thing I had to come up with was processing of arrays, which you > also see in that example JSON -- it's the specifiers that have a colon > inside the {}. The part after the colon is used as separator between > the array elements, and each element is expanded separately.) > > I'm

Re: [HACKERS] Advices on custom data type and extension development

> > Seriously, you should consider having a primary key with two > columns, of type date and int. It would take exactly the same > space as your current plan, and performance should be very close to > what you propose. As long as you aren't using some ORM that is too > dumb to deal with this, it

Re: [HACKERS] Declarative partitioning

> > > So for now, you create an empty partitioned table specifying all the > partition keys without being able to define any partitions in the same > statement. Partitions (and partitions thereof, if any) will be created > using CREATE PARTITION statements, one for each. > ...and I would assume

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Mon, Jan 25, 2016 at 2:07 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Corey Huinker <corey.huin...@gmail.com> writes: > > Incidentally, is there a reason behind the tendency of internal functions > > to avoid parameter defaults in favor of multiple pg_proc entries?

Re: [HACKERS] [POC] FETCH limited by bytes.

> > > Review: > > - There is an established idiom in postgres_fdw for how to extract > data from lists of DefElems, and this patch does something else > instead. Please make it look like postgresIsForeignRelUpdatable, > postgresGetForeignRelSize, and postgresImportForeignSchema instead of >

Re: [HACKERS] [POC] FETCH limited by bytes.

On Mon, Jan 25, 2016 at 3:22 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Mon, Jan 25, 2016 at 1:21 PM, Corey Huinker <corey.huin...@gmail.com> > wrote: > >> - We could consider folding fetch_size into "Remote Execution > >> Options", bu

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

> > > If it didn't respond to SIGINT, that would be an issue, but otherwise > this doesn't seem much more exciting than any other way to create a > query that will run longer than you want to wait. > > regards, tom lane > It responded to SIGINT, so yeah, meh. I can see

[HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

This patch addresses a personal need: nearly every time I use generate_series for timestamps, I end up casting the result into date or the ISO string thereof. Like such: SELECT d.dt::date as dt FROM generate_series('2015-01-01'::date, '2016-01-04'::date,

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Tue, Jan 26, 2016 at 7:53 AM, Michael Paquier wrote: > On Tue, Jan 26, 2016 at 7:00 PM, Torsten Zuehlsdorff > wrote: > > > > On 26.01.2016 07:52, Simon Riggs wrote: > > > >>> Imagine for example a script that in some rare cases passes

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

;stop" to match parameter name in documentation and error message On Tue, Jan 26, 2016 at 12:47 PM, Corey Huinker <corey.huin...@gmail.com> wrote: > On Tue, Jan 26, 2016 at 7:53 AM, Michael Paquier < > michael.paqu...@gmail.com> wrote: > >> On Tue, Jan 26, 201

Re: [HACKERS] Declarative partitioning

> > > The individual patches have commit messages that describe code changes. > This is registered in the upcoming CF. Feedback and review is greatly > welcomed! > > Thanks, > Amit > > We have a current system that is currently a mix of tables, each of which is range partitioned into approximately

Re: [HACKERS] Declarative partitioning

> > Also, you won't see any optimizer and executor changes. Queries will still > use the same plans as existing inheritance-based partitioned tables, > although as I mentioned, constraint exclusion won't yet kick in. That will > be fixed very shortly. > > And of course, comments on syntax are

Re: [HACKERS] Declarative partitioning

On Thu, Feb 18, 2016 at 12:41 AM, Amit Langote < langote_amit...@lab.ntt.co.jp> wrote: > START [ EXCL ] (startval) END [ INCL ] (endval) > > That is, in range type notation, '[startval, endval)' is the default > behavior. So for each partition, there is at least the following pieces of >

[HACKERS] psql metaqueries with \gexec

Often, I'm faced with a long .sql script that builds some objects, then builds things on top of them. This means that some of the queries I wish to run are dependent on the state of things that are unknown at the time of writing the script. I could give up, and make a python script that mostly

Re: [HACKERS] Re: Add generate_series(date, date) and generate_series(date, date, integer)

> > > [step] is in days, but is not documented as such. > > It is in days, and is not documented as such, but since a day is the smallest unit of time for a date, I felt there was no other interpretation. > My understanding is you want to replace this > > SELECT d.dt::date as dt > FROM

Re: [HACKERS] psql metaqueries with \gexec

> > I like what you've proposed, though I am wondering if you considered doing > something server-side instead? It seems a shame to do all this work and > exclude all other tools. > I have, but my solutions closely mirror the one you mention in the next paragraph. > I frequently find myself

Re: [HACKERS] Declarative partitioning

> > > I think we're converging on a good syntax, but I don't think the > choice of nothingness to represent an open range is a good idea, both > because it will probably create grammar conflicts now or later and > also because it actually is sort of confusing and unintuitive to read > given the

Re: [HACKERS] raw output from copy

> > >> The regression tests seem to adequately cover all new functionality, >> though I wonder if we should add some cases that highlight situations where >> BINARY mode is insufficient. >> >> One thing I tried to test RAW was to load an existing json file. My own personal test was to load an

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

removed leftover development comment On Thu, Mar 10, 2016 at 11:02 AM, Corey Huinker <corey.huin...@gmail.com> wrote: > On Thu, Mar 10, 2016 at 10:58 AM, Robert Haas <robertmh...@gmail.com> > wrote: > >> On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs <si...@2ndquad

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

On Thu, Mar 10, 2016 at 10:58 AM, Robert Haas wrote: > On Thu, Mar 10, 2016 at 10:30 AM, Simon Riggs > wrote: > > On 10 March 2016 at 06:53, Michael Paquier > > wrote: > >> > >> On Wed, Mar 9, 2016 at 12:13 AM, Alvaro

Re: [HACKERS] Soliciting Feedback on Improving Server-Side Programming Documentation

On Tue, Mar 15, 2016 at 4:38 PM, Álvaro Hernández Tortosa wrote: > > I started a similar thread with probably similar concerns: > http://www.postgresql.org/message-id/56d1a6aa.6080...@8kdata.com > > I believe this effort should be done. I added to my TODO list to >

Re: [HACKERS] psql metaqueries with \gexec

> > > I'm getting a warning from this patch: > > 1 warning generated. > Fixed that one. (note that I'm using CC='ccache clang -Qunused-arguments > -fcolor-diagnostics') > > for (r = 0; r < nrows; r++) >> { >> for (c = 0; c < ncolumns; c++) >> { >>

[HACKERS] Soliciting Feedback on Improving Server-Side Programming Documentation

Over the past few months, I've been familiarizing myself with postgres server side programming in C. My attempts to educate myself were slow and halting. The existing server side programming documentation has some examples, but those examples didn't show me how do what I wanted to do, and my

Re: [HACKERS] Soliciting Feedback on Improving Server-Side Programming Documentation

> > > I think this is all great. You may find some automated assistance from > doxygen.postgresql.org . > > Sincerely, > > JD doxygen is great as far as it goes, but it does a great job of separating function definition from the comment explaining the function, so I have to drill into the raw

Re: [HACKERS] Soliciting Feedback on Improving Server-Side Programming Documentation

On Tue, Mar 15, 2016 at 1:19 PM, Shulgin, Oleksandr < oleksandr.shul...@zalando.de> wrote: > There's also a good deal of README files in the source tree, so I would > add: > > 4. find src -name 'README*' > That too. But README's don't show up (easily) in a google search, so they elude discovery.

Re: [HACKERS] Soliciting Feedback on Improving Server-Side Programming Documentation

On Tue, Mar 15, 2016 at 1:35 PM, Joshua D. Drake <j...@commandprompt.com> wrote: > On 03/15/2016 10:30 AM, Corey Huinker wrote: > >> >> On Tue, Mar 15, 2016 at 1:19 PM, Shulgin, Oleksandr >> <oleksandr.shul...@zalando.de <mailto:oleksandr.shul...@zalando.d

Re: [HACKERS] Declarative partitioning

> > > So presently partitions that are unbounded on the lower end aren't > > possible, but that's a creation syntax issue, not an infrastructure > issue. > > Correct? > > In case it wasn't apparent, you can create those: > > FOR VALUES END (upper-bound) [INCLUSIVE] > > which is equivalent to: > >

Re: [HACKERS] Add generate_series(date,date) and generate_series(date,date,integer)

> > > It would be simple enough to remove the infinity test on the "stop" and > > leave it on the "start". Or yank both. Just waiting for others to agree > > which checks should remain. > > Let's yank 'em. This is a minor issue which is distracting us from > the main point of this patch, and I

Re: [HACKERS] Declarative partitioning

> > Sorry for replying so late. > No worries! We have jobs to do aside from this. > > Everything seemed to go dandy until I tried FOR VALUES (blah , blah], > where psql wouldn't send the command string without accepting the closing > parenthesis, :(. So maybe I should try to put the whole

  1   2   3   4   >