On Sat, May 11, 2013 at 07:22:55PM -0400, Robert Haas wrote:
On Sat, May 11, 2013 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
By the time you've got an expression tree, the problem is mostly solved,
at least so far as parser extension is concerned.
Right.
More years ago than I care
I have actually been working on the task discussed in this thread, most relevant
parts quoted below, for awhile now, and hope to have something concrete that you
can use by the end of this summer.
My in-development Muldis D language is homoiconic as a core feature, its source
code is data to
On Sunday, May 12, 2013 4:53 AM Robert Haas wrote:
On Sat, May 11, 2013 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
By the time you've got an expression tree, the problem is mostly
solved,
at least so far as parser extension is concerned.
Right.
More years ago than I care to
On Sun, May 12, 2013 at 1:18 PM, Jim Nasby j...@nasby.net wrote:
FWIW, I've wanted the ability to plug into the parser not for an extension,
but so that I could programmaticly enforce certain coding conventions.
Depending on the exact requirements, that probably wouldn't be too
difficult. It'd
On 5/11/13 11:27 AM, Tom Lane wrote:
David Fetter da...@fetter.org writes:
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
Some kind of extendable parser would be awesome. It would need to tie
into the rewriter also.
No, I don't have a clue what the design looks like.
That's
On Thu, May 9, 2013 at 7:36 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Some of this is getting solved by making PostgreSQL more pluggable in
ways that isolate the proprietary stuff, i.e. make people not have to
touch the PostgreSQL core code much, if at all, in order to provide
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
On Thu, May 9, 2013 at 7:36 AM, Michael Paquier
michael.paqu...@gmail.com wrote:
Some of this is getting solved by making PostgreSQL more pluggable in
ways that isolate the proprietary stuff, i.e. make people not have to
touch
David Fetter da...@fetter.org writes:
On Sat, May 11, 2013 at 11:17:03AM -0400, Robert Haas wrote:
Some kind of extendable parser would be awesome. It would need to tie
into the rewriter also.
No, I don't have a clue what the design looks like.
That's a direction several of the
On Sat, May 11, 2013 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
By the time you've got an expression tree, the problem is mostly solved,
at least so far as parser extension is concerned.
Right.
More years ago than I care to admit, I worked on systems that had
run-time-extensible parsers
On Thu, May 9, 2013 at 9:12 AM, David Fetter da...@fetter.org wrote:
On Wed, May 08, 2013 at 06:08:28PM -0500, Jim Nasby wrote:
I believe that makes it significantly harder for them to actually
contribute code back that doesn't give them a business advantage, as
well as making it harder to
On 5/1/13 7:36 PM, Robert Haas wrote:
On Mon, Apr 29, 2013 at 4:33 PM, Jim Nasbyj...@nasby.net wrote:
On 4/28/13 7:50 AM, Craig Ringer wrote:
I find it frustrating that I've never seen an @paraccel email address here
and that few of the other vendors of highly customised Pg offshoots are
On Wed, May 08, 2013 at 06:08:28PM -0500, Jim Nasby wrote:
On 5/1/13 7:36 PM, Robert Haas wrote:
On Mon, Apr 29, 2013 at 4:33 PM, Jim Nasbyj...@nasby.net wrote:
On 4/28/13 7:50 AM, Craig Ringer wrote:
I find it frustrating that I've never seen an @paraccel email address
here
and that few
On Mon, Apr 29, 2013 at 4:33 PM, Jim Nasby j...@nasby.net wrote:
On 4/28/13 7:50 AM, Craig Ringer wrote:
I find it frustrating that I've never seen an @paraccel email address here
and that few of the other vendors of highly customised Pg offshoots are
contributing back. It's almost enough to
I find it frustrating that I've never seen an @paraccel email address
here and that few of the other vendors of highly customised Pg offshoots
are contributing back. It's almost enough to make me like the GPL.
Well, Paraccel never ended up contributing any code, but in years back
(2006-2008)
On 05/02/2013 08:36 AM, Robert Haas wrote:
I've talked with a bunch of other companies over the last few years
who also chose PostgreSQL for licensing reasons. I'm pretty happy
about that.
I think it's a pretty good thing too, personally ... but I do wish
they'd contribute a bit more to the
Robert Haas robertmh...@gmail.com writes:
... There are in fact a
pretty large number of companies - EnterpriseDB, obviously, but there
are many, many others - that are choosing to build businesses around
PostgreSQL precisely because it *isn't* GPL. Personally, I think
that's a good thing
On 4/28/13 7:50 AM, Craig Ringer wrote:
I find it frustrating that I've never seen an @paraccel email address here and
that few of the other vendors of highly customised Pg offshoots are
contributing back. It's almost enough to make me like the GPL.
FWIW, I think there's a pretty large
On 04/25/2013 10:55 PM, Andrew Dunstan wrote:
It's an Amazon product based on release 8.0, but with many many
features removed (e.g. Indexes!)
More specifically, it's a hacked-up column-store-ized Pg for OLAP and
analytics work. As I understand it Amazon didn't develop it themselves;
they
Christopher Manning c...@christophermanning.org writes:
Fabrízio and Tom,
I know that you can use --variable=FETCH_COUNT=1 from the
psql command line, but internally that uses a CURSOR to batch the rows and
[Redshift doesn't support CURSOR](
On 04/25/2013 10:42 AM, Tom Lane wrote:
Christopher Manning c...@christophermanning.org writes:
Fabrízio and Tom,
I know that you can use --variable=FETCH_COUNT=1 from the
psql command line, but internally that uses a CURSOR to batch the rows and
[Redshift doesn't support CURSOR](
On 04/25/2013 07:42 AM, Tom Lane wrote:
Christopher Manning c...@christophermanning.org writes:
Fabr�zio and Tom,
I know that you can use --variable=FETCH_COUNT=1 from the
psql command line, but internally that uses a CURSOR to batch the rows and
[Redshift doesn't support CURSOR](
On Tue, Apr 23, 2013 at 1:05 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Isn't there already a way to set FETCH_COUNT from the command line?
(ie, I think there's a generic variable-assignment facility that could
do this)
Christopher,
Tom is all right... from psql [1] command line we can do that:
Fabrízio and Tom,
I know that you can use --variable=FETCH_COUNT=1 from the
psql command line, but internally that uses a CURSOR to batch the rows and
[Redshift doesn't support CURSOR](
https://forums.aws.amazon.com/thread.jspa?threadID=122664tstart=0) so it's
not an option when using psql
Hello
It is redundant to current FETCH_COUNT implementation, so I don't see sense
to use it together. Maybe we can drop FETCH_COUNT and replace it by
--single-row mode and probably it can simplify code.
Regards
Pavel
2013/4/23 Christopher Manning c...@christophermanning.org
psql currently
Christopher Manning c...@christophermanning.org writes:
I'm proposing to add a --single-row option to psql that would allow the
result rows of a query to be streamed to a file without collecting them in
memory first.
Isn't there already a way to set FETCH_COUNT from the command line?
(ie, I
25 matches
Mail list logo
