On Sat, Feb 27, 2016 at 2:26 AM, Pavel Stehule
wrote:
> Hi
>
> 2015-08-06 10:37 GMT+02:00 Pavel Stehule :
>
>> Hi,
>>
>> Psql based implementation needs new infrastructure (more than few lines)
>>
>> Missing:
>>
>> * binary mode support
>> * parametrized query support,
>>
>> I am not against, but
>
>
> I feel rather uneasy about simply removing the 'infinity' checks. Is there
> a way to differentiate those two cases, i.e. when the generate_series is
> called in target list and in the FROM part? If yes, we could do the check
> only in the FROM part, which is the case that does not work (and
>
> > 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 don
>
> 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 thing
>
> > 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:
>
> F
>
>
>> 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 exis
>
>
> 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 res
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 Herrera
> >> wrote:
> >> > Robert Haas wrote:
> >> >> I'm pretty meh about t
removed leftover development comment
On Thu, Mar 10, 2016 at 11:02 AM, Corey Huinker
wrote:
> 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
>
>
> 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++)
>> {
>>
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 resea
>
>
> 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 sou
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.
On Tue, Mar 15, 2016 at 1:35 PM, Joshua D. Drake
wrote:
> On 03/15/2016 10:30 AM, Corey Huinker wrote:
>
>>
>> On Tue, Mar 15, 2016 at 1:19 PM, Shulgin, Oleksandr
>> mailto:oleksandr.shul...@zalando.de>>
>> wrote:
>>
>> There's also
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
> compile a list of used
On Thu, Mar 17, 2016 at 10:00 AM, David Steele wrote:
> On 3/17/16 4:49 AM, Dean Rasheed wrote:
>
> > On 16 March 2016 at 23:32, David Steele wrote:
> >
> >>
> >> I think in this case it comes down to a committer's judgement so I have
> >> marked this "ready for committer" and passed the buck on
On Thu, Mar 17, 2016 at 11:30 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> I'd call it "generate_dates(...)" and be done with it.
>
Sold. Hope to have a revised patch for you today or tomorrow.
On Thu, Mar 17, 2016 at 12:04 PM, Tom Lane wrote:
> David Steele writes:
> > On 3/17/16 11:30 AM, David G. Johnston wrote:
> >> I'd call it "generate_dates(...)" and be done with it.
> >> We would then have:
> >> generate_series()
> >> generate_subscripts()
> >> generate_dates()
>
> > To me thi
>
>
> 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 ... TABLESP
>
> 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
>
>
> 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 t
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,
i
>
>
> 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 val
On Mon, Jan 25, 2016 at 2:07 AM, Tom Lane wrote:
> Corey Huinker writes:
> > Incidentally, is there a reason behind the tendency of internal functions
> > to avoid parameter defaults in favor of multiple pg_proc entries?
>
> Yes: you can't specify defaults in pg_proc.
>
>
> 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
> invent
On Mon, Jan 25, 2016 at 3:22 PM, Robert Haas wrote:
> On Mon, Jan 25, 2016 at 1:21 PM, Corey Huinker
> wrote:
> >> - We could consider folding fetch_size into "Remote Execution
> >> Options", but maybe that's too clever.
> >
> > If you care to
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 happens to
> >>> pass infinity into generate_series() - in
amed "stop" to match parameter name in
documentation and error message
On Tue, Jan 26, 2016 at 12:47 PM, Corey Huinker
wrote:
> On Tue, Jan 26, 2016 at 7:53 AM, Michael Paquier <
> michael.paqu...@gmail.com> wrote:
>
>> On Tue, Jan 26, 2016 at 7:00 PM, Torsten Z
>
>
> 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 see
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 y
>
>
> > 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, u
>
>
> 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.
> ^
> ../../src/includ
>
>
> 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 a/cont
>
> 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 otherwi
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 I don't want, because that means that
CREATE
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
> wrote:
>
>>
>> Oh, and I suggest we call them SESSION variables rather than SCHEMA
>> variables, to reinforce the idea of how
>
>
> 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
>
> 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 welco
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
> metadata:
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 ju
>
>
> [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 generate_
>
> 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 crea
On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite
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 set
> > up, and if t
On Mon, Feb 22, 2016 at 11:30 AM, Corey Huinker
wrote:
> On Mon, Feb 22, 2016 at 10:08 AM, Daniel Verite
> wrote:
>
>> Corey Huinker wrote:
>>
>> > ...and query text visibility, and result visibility, and error handling,
>> > etc. In this case, we&
>
> 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
>
> >
> > 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 checking
>
> (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 splitting
>
> 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);
>
Goo
On Tue, Aug 16, 2016 at 9:29 PM, Tom Lane wrote:
> Jim Nasby writes:
> > I can't think of any reason you'd want two different range types on a
> > single element type.
>
> We would not have built it that way if there were not clear use-cases.
> An easy example is you might want both a continuous
I'd be happy to roll your code into the extension, and make it marked more
stable.
On Thu, Aug 18, 2016 at 2:49 PM, Jim Nasby wrote:
> On 8/18/16 1:06 PM, Corey Huinker wrote:
>
>> You might also find some gleanable gems in:
>> https://github.com/moat/range_type_fu
On Fri, Aug 19, 2016 at 11:40 AM, Jim Nasby
wrote:
> On 8/18/16 6:02 PM, Corey Huinker wrote:
>
>> I'd be happy to roll your code into the extension, and make it marked
>> more stable.
>>
>
> Yeah, I've been meaning to look at submitting a pull request;
On Wed, Aug 24, 2016 at 10:36 PM, Gerdan Santos wrote:
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, passed
> Spec compliant: tested, passed
> Documentation:tested, pa
On Wed, Aug 31, 2016 at 11:32 AM, Pavel Stehule
wrote:
> Hi
>
> I propose a new type of psql variables - file references. The content of
> file reference is specified by referenced file. It allows simple inserting
> large data without necessity of manual escaping or using LO api.
>
> When I wrote
On Wed, Aug 24, 2016 at 12:39 PM, Andres Freund wrote:
>
>
> On August 24, 2016 9:32:48 AM PDT, Tomas Vondra <
> tomas.von...@2ndquadrant.com> wrote:
> >
> >
> >On 08/24/2016 12:20 AM, Andres Freund wrote:
> >> On 2016-08-23 19:18:04 -0300, Claudio Freire wrote:
> >>> On Tue, Aug 23, 2016 at 7:11
On Wed, Aug 31, 2016 at 6:07 PM, Andres Freund wrote:
>
> In my experience pg attribute is usually the worst affected. Many tech
> takes won't even have stays entries...
>
>
Mine too. One database currently has a 400GB pg_attribute table, because we
chew through temp tables like popcorn.
On Thu, Sep 1, 2016 at 2:17 PM, Tom Lane wrote:
> I wrote:
> > So for clarity's sake: first suitable format among these:
>
> > Time: 59.999 ms
> > Time: 121.999 ms (2:01.999)
> > Time: 10921.999 ms (3:02:01.999)
> > Time: 356521.999 ms (4 3:02:01.999)
>
> Sorry, that probably added no clarity at
On Thu, Sep 1, 2016 at 2:43 PM, Tom Lane wrote:
> I wrote:
> > Sorry, that probably added no clarity at all, I was confusing
> > seconds with milliseconds in the example values :-(
>
> After a bit of further fooling with sample values, I propose this
> progression:
>
> Time: 0.100 ms
> Time: 1.20
On Thu, Sep 1, 2016 at 3:01 PM, Tom Lane wrote:
> Corey Huinker writes:
> > On Thu, Sep 1, 2016 at 2:43 PM, Tom Lane wrote:
> >> Note that times from 1 second to 1 hour all get the nn:nn.nnn
> >> treatment. I experimented with these variants for sub-minute times:
On Fri, Sep 2, 2016 at 5:07 AM, Amit Langote
wrote:
>
> I am not familiar with win32 stuff too, so I don't have much to say about
> that. Maybe someone else can chime in to help with that.
>
The regressions basically *can't* test this because we'd need a shell
command we know works on any archi
On Sun, Sep 4, 2016 at 7:05 PM, Jim Nasby wrote:
> On 9/3/16 2:35 PM, Tom Lane wrote:
>
>> I pushed the patch using this:
>>
>> Time: 176460001.200 ms (2 d 01:01:00.001)
>>
>> and all else as before.
>>
>
> I'd find this useful in the final output of EXPLAIN ANALYZE as well; any
> objections to a
On Tue, Sep 6, 2016 at 6:53 PM, Craig Ringer
wrote:
> On 7 Sep. 2016 02:14, "Corey Huinker" wrote:
> >
>
> > Having regression tests for this is extremely problematic, because the
> program invoked would need to be an invokable command on any architecture
>
On Tue, Sep 6, 2016 at 9:46 PM, Amit Langote
wrote:
> On 2016/09/07 3:12, Corey Huinker wrote:
> > On Fri, Sep 2, 2016 at 5:07 AM, Amit Langote wrote:
> >> I am not familiar with win32 stuff too, so I don't have much to say
> about
> >> that. Maybe someone
On Tue, Sep 6, 2016 at 11:24 PM, Craig Ringer
wrote:
> On 7 September 2016 at 11:21, Corey Huinker
> wrote:
> > On Tue, Sep 6, 2016 at 6:53 PM, Craig Ringer <
> craig.rin...@2ndquadrant.com>
>
> > And the TAP test would detect the operating system and know to cr
>
> ... and it would probably greatly reduce the amount of mailing list
> traffic asking for version if nothing else.
That was the major reason for wanting it.
The second is that if an explain were posted to a forum like stackexchange,
the reader wouldn't have to wonder what version produced the
On Tue, Sep 6, 2016 at 11:44 PM, Craig Ringer
wrote:
> On 7 September 2016 at 11:37, Corey Huinker
> wrote:
> > On Tue, Sep 6, 2016 at 11:24 PM, Craig Ringer <
> craig.rin...@2ndquadrant.com>
> > wrote:
> >>
> >> On 7 September 2016 at 11:21, Co
On Thu, Sep 8, 2016 at 6:59 PM, Craig Ringer
wrote:
> On 9 Sep. 2016 03:45, "Corey Huinker" wrote:
> >
> >
>
> > Stylistically, would a separate .pl file for the emitter be preferable
> to something inline like
> >
> >> perl -e 'print &qu
wording change in C comments
On Thu, Sep 8, 2016 at 6:59 PM, Craig Ringer
wrote:
> On 9 Sep. 2016 03:45, "Corey Huinker" wrote:
> >
> >
>
> > Stylistically, would a separate .pl file for the emitter be preferable
> to something inline like
> >
> >>
ut I can see where a less familiar reader would take the
meaning to be "has permission to see the value already set". Either way, it
now mentions program as an option in addition to filename.
On Mon, Sep 12, 2016 at 1:59 AM, Amit Langote wrote:
> On 2016/09/11 8:04, Corey Huinker wrote:
On Mon, Sep 12, 2016 at 1:59 AM, Amit Langote wrote:
> On 2016/09/11 8:04, Corey Huinker wrote:
> > V2 of this patch:
> >
> > Changes:
> > * rebased to most recent master
> > * removed non-tap test that assumed the existence of Unix sed program
> > * added
Attached is a _very_ rough patch implementing a proof-of-concept function
copy_srf();
It allows you to do things like this:
# select a,c,e from copy_srf('echo 12,345,67,89,2016-01-01',true) as t(a
integer, b text, c text, d text, e date);
a | c | e
++
12 | 67 | 2016-01
On Fri, Oct 7, 2016 at 5:09 PM, Tom Lane wrote:
> What seems like a saner answer to me is to change the backend so that it
> will accept these ALTER commands in either order, with the same end state.
> The reason it throws an error now, IMO, is just so that blindly issuing
> the same ALTER ADD CO
>
> here is new update - some mentioned issues are fixed + regress tests and
>> docs
>>
>
>
>
This might tie into some work I'm doing. Is there any way these filerefs
could be used as the inline portion of a COPY command?
i.e. like this:
COPY my_table FROM STDIN
:file_ref
\.
On Sun, Oct 9, 2016 at 12:12 PM, Pavel Stehule
wrote:
>
>
> 2016-10-09 17:27 GMT+02:00 Corey Huinker :
>
>> here is new update - some mentioned issues are fixed + regress tests and
>>>> docs
>>>>
>>>
>>>
>>>
>> This migh
>
> look to code - some parts allows psql session variables, some not - I can
> use variables in statements - not in data block.
>
> More, there is ambiguity - :xxx should not be part of SQL statement (and
> then psql variables are possible), but : should be part of data.
>
> Regards
>
> Pavel
>
>
> There's actually another use case here that's potentially extremely
> valuable for warehousing and other "big data": compact representation of a
> default value.
>
>
I too would benefit from tables having either a default value in the event
of a NOT-NULL column being flagged null, or a flat-o
On Sun, Oct 9, 2016 at 11:26 PM, Jim Nasby wrote:
> On 10/9/16 9:54 PM, Bruce Momjian wrote:
>
>> I understand, but I am not sure how difficult implementation it is. This
>>> part
>>> > (COPY input) doesn't support parametrization - and parametrization can
>>> have a
>>> > negative performance im
>
> > That sounds fantastic. It'd help this copy variant retain festure parity
> > with normal copy. And it'd bring us closer to being able to FETCH in non
> > queries.
>
> On second thought, though, this couldn't exactly duplicate the existing
> COPY syntax, because COPY relies heavily on the rowt
On Sun, Oct 16, 2016 at 9:01 AM, Craig Ringer
wrote:
> On 15 Oct. 2016 04:56, "Corey Huinker" wrote:
>
> > I would like to make COPY itself a SRF. That's a bit beyond my
> capabilities, so if that is the route we want to go, I will need help.
> >
> >
On Tue, Oct 18, 2016 at 12:26 PM, Jonathan Jacobson
wrote:
> The .psql_history file is naturally used by different DB connections
> (distinguished by a different combination of host + port + database + user).
> At least in my multi-database working environment, this leads sometimes to
> frustrati
Attached is a patch that implements copy_srf().
The function signature reflects cstate more than it reflects the COPY
options (filename+is_program instead of FILENAME or PROGRAM, etc)
CREATE OR REPLACE FUNCTION copy_srf(
filenametext DEFAULT null,
is_program boolean DEFAULT false,
On Sun, Oct 30, 2016 at 11:37 PM, Jim Nasby
wrote:
> BTW, I've sometimes wished for a mode where queries would silently have
> result ordering intentionally futzed, to eliminate any possibility of
> dependence on tuple ordering (as well as having sequences start at some
> random value). I guess w
On Tue, Nov 1, 2016 at 12:57 PM, Robert Haas wrote:
> For strings and numeric types that are not integers, there is in
> theory a loss of power. If you want a partition that allows very
> value starting with 'a' plus the string 'b' but not anything after
> that, you are out of luck. START ('a')
On Tue, Nov 1, 2016 at 2:01 PM, Robert Haas wrote:
> Yeah. That syntax has some big advantages, though. If we define that
> partition as START ('2014-01-01') INCLUSIVE END ('2014-12-31')
> INCLUSIVE, there's no way for the system to tell that the there's no
> gap between the that ending bound a
>
> OTOH I've seen a lot of people bitten by [2014-01-01,2014-12-31] on
> TIMESTAMP intervals.
>
No argument there.
> Everybody remembers december has 31 days, but when we have to do
> MONTHLY partitions if you use closed intervals someone always miskeys
> the number of days, or forgets wheter a
On Tue, Nov 1, 2016 at 2:24 PM, Robert Haas wrote:
> Well, I'm not sure we've exactly reached consensus here, and you're
> making me feel like I just kicked a puppy.
>
It was hyperbole. I hope you found it as funny to read as I did to write.
This is a great feature and I'm not going to make "per
>
>
> ALTER TABLE my_table
> DISABLE INDEX ALL;
>
+1
This very thing came up in a conversation with PeterG early last year. I
was in favor then and I was surprised that the only thing standing in the
way was a lack of ALTER TABLE syntax.
Creating temporary data structures to mimic existing met
Craig's post yesterday about exposing syntax for disabling indexes reminded
me of another feature I think we're lacking in areas where we have to do
table management.
The issue is to create a *something* that has the exact permissions of
another *something*. Usually it's creating a table related t
>
> > SET relacl = ( SELECT relacl FROM pg_class
> >WHERE oid = 'foo'::regclass)
> > WHERE oid = 'dummy'::regclass;
>
> Yikes, let's not suggest folks go updating catalog tables, ever, please.
> :)
>
Glad you find that as icky as I do.
> Should we have a way for users to
On Wed, Nov 9, 2016 at 10:47 AM, Tom Lane wrote:
> Yeah, that's the thread I remembered. I think the basic conclusion was
> that we needed a Perl script that would suck up a bunch of data from some
> representation that's more edit-friendly than the DATA lines, expand
> symbolic representations
On Thu, Nov 10, 2016 at 6:41 PM, Tom Lane wrote:
> I think you've fundamentally missed the point here. A data dump from a
> table would be semantically indistinguishable from the lots-o-DATA-lines
> representation we have now. What we want is something that isn't that.
> In particular I don't s
On Sun, Nov 13, 2016 at 1:46 PM, Pavel Stehule
wrote:
> r - read file without any modification
> rq - read file, escape as literal and use outer quotes
> rb - read binary file - transform to hex code string
> rbq - read binary file, transform to hex code string and use outer quotes
>
> Usage:
I
I ran into this today:
select current_database() as current_db \gset
CREATE EXTENSION postgres_fdw;
CREATE EXTENSION
CREATE EXTENSION dblink;
CREATE EXTENSION
CREATE ROLE bob LOGIN PASSWORD 'bob';
CREATE ROLE
CREATE SERVER bob_srv FOREIGN DATA WRAPPER postgres_fdw OPTIONS ( host
'localhost', dbnam
>
> The dblink docs recommend using dblink_fdw as the FDW for this purpose,
> which would only accept legal connstr options. However, I can see the
> point of using a postgres_fdw server instead, and considering that
> dblink isn't actually enforcing use of any particular FDW type, it seems
> like
On Sun, Feb 19, 2017 at 9:04 AM, Robert Haas wrote:
If you tried to write an SQL-callable function that internally started
> and ended a copy from the client, then I think you would run into this
> problem, and probably some others.
>
>
That's it. I had a PoC patch submitted that allowed someone
>
> but if you think that it should be somewhere else, please advise Corey
> about where to put it.
Just a reminder that I'm standing by for advice.
The issue at hand is whether the if-state should be a part of the
PsqlScanState, or if it should be a separate state variable owned by
MainLoop()
On Wed, Feb 22, 2017 at 4:00 PM, Tom Lane wrote:
> Corey Huinker writes:
> >> but if you think that it should be somewhere else, please advise Corey
> >> about where to put it.
>
> > Just a reminder that I'm standing by for advice.
>
> Sorry, I'
>
>
> Dunno, that sounds a lot like an "if the only tool I have is a hammer,
> then this must be a nail" argument.
More of a "don't rock the boat more than absolutely necessary", but knowing
that adding another global struct might be welcomed is good to know.
> reasonable interpretation of what
On Wed, Feb 22, 2017 at 5:11 PM, Corey Huinker
wrote:
> Dunno, that sounds a lot like an "if the only tool I have is a hammer,
>> then this must be a nail" argument.
>
>
> More of a "don't rock the boat more than absolutely necessary", but
> know
On Wed, Feb 22, 2017 at 5:59 PM, Tom Lane wrote:
> Ah, I see why *that* wants to know about it ... I think. I suppose you're
> arguing that variable expansion shouldn't be able to insert, say, an \else
> in a non-active branch? Maybe, but if it can insert an \else in an active
> branch, then wh
On Wed, Feb 22, 2017 at 6:15 PM, Corey Huinker
wrote:
> On Wed, Feb 22, 2017 at 5:59 PM, Tom Lane wrote:
>
>> Ah, I see why *that* wants to know about it ... I think. I suppose you're
>> arguing that variable expansion shouldn't be able to insert, say, an \el
1 - 100 of 313 matches
Mail list logo
