On Fri, Feb 6, 2015 at 11:04 PM, Robert Haas wrote:
>
> On Fri, Feb 6, 2015 at 9:43 AM, Amit Kapila
wrote:
> > Here is the latest patch which fixes reported issues and supported
> > Prepared Statements and Explain Statement for parallel sequential
> > scan.
> >
> > The main purpose is to get the
On Sat, Feb 7, 2015 at 2:30 AM, Robert Haas wrote:
>
> On Fri, Feb 6, 2015 at 2:13 PM, Robert Haas wrote:
> > The complicated part here seems to me to figure out what we need to
> > pass from the parallel leader to the parallel worker to create enough
> > state for quals and projection. If we wa
Thanks for your reply.
>> Feature test
>>
(snip)
> I thought about using a
> special value like -2 to define the behavior you are mentioning here,
> aka with "-2" disable custom value and GUC parameter but I don't think
> it is worth adding as that's an ugly 3 line of code of
On 09-02-2015 AM 10:21, Tom Lane wrote:
>
> Meh. I don't care for that much --- it sounds a lot like deciding that
> your problem is a nail because there is a hammer within reach. A random
> collection of ranges doesn't seem like a very appropriate representation
> to me; first because there is
On 02/09/2015 03:21 AM, Tom Lane wrote:
Amit Langote writes:
On 07-02-2015 AM 12:10, Tom Lane wrote:
There is no good reason to assume that a range type exists at all, much
less that it is unique for a subtype. (Read the CREATE TYPE documentation
if you're unclear as to why not.) You have no
On Fri, Feb 6, 2015 at 3:42 AM, Michael Paquier
wrote:
> Fujii Masao wrote:
>> I wrote
>>> This is an inspiration from lz4 APIs. Wouldn't it be buggy for a
>>> compression algorithm to return a size of 0 bytes as compressed or
>>> decompressed length btw? We could as well make it return a negative
>>> Although that might be taking this thread rather far off-topic.
>> Not really sure about that, because the only outstanding objection to
>> this discussion is what happens in the startup stage if you specify -f.
>> Right now vacuum is attempted on the standard tables, which is probably
>> not t
Amit Langote writes:
> On 07-02-2015 AM 12:10, Tom Lane wrote:
>> There is no good reason to assume that a range type exists at all, much
>> less that it is unique for a subtype. (Read the CREATE TYPE documentation
>> if you're unclear as to why not.) You have not said what you're trying to
>> a
On 2/2/15 3:49 PM, David Steele wrote:
> The role-base approach being considered may strike some as a misuse of
> the role system, but to my eye it is syntactically very close to how
> Oracle does auditing prior to 12c. Say you wanted to audit selects on
> the table hr.employee:
>
> Oracle: AUDIT
On 07-02-2015 AM 12:10, Tom Lane wrote:
> Amit Langote writes:
>> I wonder why I cannot find a way to get a range type for a given (sub-)
>> type. I would like to build a RangeType from Datum's of lower and upper
>> bounds. Much like how construct_array() builds an ArrayType from a Datum
>> array
Ryan Kelly writes:
> On Tue, Feb 3, 2015 at 11:10 AM, Tom Lane wrote:
>> It's probably not reasonable to add a pstate argument to
>> LookupExplicitNamespace itself, given that namespace.c isn't part
>> of the parser. But you could imagine adding an interface function
>> in the parser that calls
At 2015-02-08 18:46:30 +0200, hlinnakan...@vmware.com wrote:
>
> So I propose to move pg_crc.c to src/common, and move the tables
> from pg_crc_tables.h directly to pg_crc.c. Thoughts?
Sounds fine to me.
-- Abhijit
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make c
On Tue, Feb 3, 2015 at 11:10 AM, Tom Lane wrote:
> Ryan Kelly writes:
>> The attached patch adds a LINE: ... hint when schemaname.typename
>> results in a schema which does not exist. I came across this when a
>> missing comma in a SELECT list resulted in an error without a location
>> in a query
On Sat, Feb 7, 2015 at 10:36 PM, Amit Kapila wrote:
>> Well, I agree with you, but I'm not really sure what that has to do
>> with the issue at hand. I mean, if we were to apply Amit's patch,
>> we'd been in a situation where, for a non-parallel heap scan, heapam.c
>> decides the order in which b
On Sun, Feb 8, 2015 at 11:04 AM, Magnus Hagander wrote:
> Filenames are now shown for attachments, including a direct link to the
> attachment itself. I've also run a job to populate all old threads.
Thanks!
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Com
On Sun, Feb 8, 2015 at 11:31 AM, Noah Misch wrote:
> On Sat, Feb 07, 2015 at 08:18:55PM -0500, Robert Haas wrote:
>> There are a few problems with this design that I don't immediately
>> know how to solve:
>>
>> 1. I'm concerned that the query-rewrite step could substitute a query
>> that is not p
On 2015-02-08 18:46:30 +0200, Heikki Linnakangas wrote:
> So I propose to move pg_crc.c to src/common, and move the tables from
> pg_crc_tables.h directly to pg_crc.c. Thoughts?
+1.
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Developme
On 01/09/2015 10:32 AM, Abhijit Menon-Sen wrote:
1. The slicing-by-8 patch contains numerous changes:
With this patch, CALC_CRC32C is no longer a pure macro, but includes a
function call. That means that you can no longer just #include pg_crc.h
and pg_crc_tables.h in an external program. We m
On Sat, Feb 07, 2015 at 08:18:55PM -0500, Robert Haas wrote:
> There are a few problems with this design that I don't immediately
> know how to solve:
>
> 1. I'm concerned that the query-rewrite step could substitute a query
> that is not parallel-safe for one that is. The upper Query might
> sti
On Wed, Feb 04, 2015 at 10:07:07AM -0500, Tom Lane wrote:
> Michael Meskes would be the authority on that question, so I've cc'd
> him to make sure he notices this thread ...
Thanks Tom.
> > The leaks were in the code that takes a host variable, and converts it
> > into a string for sending to t
On Sat, Feb 7, 2015 at 1:46 PM, Magnus Hagander wrote:
> On Sat, Feb 7, 2015 at 1:02 AM, Jeff Janes wrote:
>
>>
>>>
>>> One thing that would probably *help* is if the list of attachments
>>> mentioned the names of the files that were attached to each message
>>> rather than just noting that they
On 2015-02-08 09:56, Shay Rojansky wrote:
More to the point, doesn't max_rows=1 have exactly the same dangers as
LIMIT 1? The two seem to be identical, except that one is expressed in
the
SQL query and the other at the network protocol level.
The planner does not have access to network proto
First a general comment:
> Then the driver writers that need these special API behaviors are
> reasonably expected to contribute to adding them to backend products that
> do not already have them. The database developers are not going to take
on
> responsibility for the API decisions of others; a
23 matches
Mail list logo