On 2 July 2013 09:30, Dean Rasheed wrote:
> I think the rewritten query should only use inheritance if inheritance
> was requested in the original query, *and* if inheritance was enabled
> in the view's query, per attached patch against HEAD.
On second thoughts, I think this should
On 2 July 2013 08:44, Rushabh Lathia wrote:
> Looking further I just found that, if we don't want query to scan through
> child table then we should use ONLY during CREATE VIEW.
>
> So if I replaced my create view query with:
>
> CREATE view view_tp_sales as SELECT * FROM ONLY tp_sales;
>
> Then I
On 3 February 2013 09:16, Dean Rasheed wrote:
>> It looks like what the code is actually computing is the average X
>> position and average Y position of the points listed in the polygon.
Although, if that's really how it's being calculated, then that's not
really
On 1 February 2013 22:16, Tom Lane wrote:
> Colin Dunklau writes:
>> Hello! I believe I've found a bug in the type conversion process from
>> polygon to point.
>
>> In the documentation found here
>> http://www.postgresql.org/docs/9.2/interactive/functions-geometry.html,
>
>> Table 9-32 claims th
On 12 June 2012 21:27, Josh Kupershmidt wrote:
> On Sat, Jun 9, 2012 at 2:40 AM, Dean Rasheed wrote:
>
>> I noticed this while testing 9.2, but it seems to go back to at least
>> 8.3. Tab completion of function arguments doesn't work if the function
>> is schema-q
Hi,
I noticed this while testing 9.2, but it seems to go back to at least
8.3. Tab completion of function arguments doesn't work if the function
is schema-qualified or double-quoted. So for example,
DROP FUNCTION my_function (
completes the functions arguments, but
DROP FUNCTION my_schema.
> 2011/6/28 Renat :
>>
>> create table foo (
>> id bigint not null,
>> date_to timestamp without time zone,
>> CONSTRAINT foo_pkey PRIMARY KEY (id)
>> );
>>
>> CREATE INDEX foo_date_to_index
>> ON foo
>> USING btree
>> (date_to)
>>
>> insert into foo (id, date_to) values (1, now());
>> insert in
Testing 9.1beta:
select format('Hello %s, %2147483648$s', 'World');
server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.
The problem i
On 15 October 2010 05:58, Vince wrote:
>
> The following bug has been logged online:
>
> Bug reference: 5711
> Logged by: Vince
> Email address: vincecar...@gmail.com
> PostgreSQL version: 8.4
> Operating system: Linux
> Description: input out of error with haversine fo
>> Now comes the "religious" discussion. The above design works well for
>> Oracle, DB2 and MySQL, etc. But PostgresQL seems to choke. It complains
>> about the data type mismatch. By reading various discussions on your
>> forum,
>> there seems to some issues with the data type mapping at the JDBC
Sorry, I meant to cc this to -bugs as well as -hackers
-- Forwarded message --
From: Dean Rasheed
Date: 18 August 2010 18:29
Subject: Per-tuple memory leak in 9.0
To: pgsql-hack...@postgresql.org
While testing triggers, I came across the following memory leak.
Here's a s
On 6 August 2010 16:25, Tom Lane wrote:
> Frank Heikens writes:
>>> http://wiki.postgresql.org/wiki/What%27s_new_in_PostgreSQL_9.0#DEFERRABLE_UNIQUE_CONSTRAINTS
>
>>> I don't have to ask PostgreSQL to defer, it works in the second test
>>> as well in the third test without any changes. I guess th
On 9 June 2010 20:56, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
>> Dean Rasheed writes:
>>> Hmm. Well it's quite subjective, but IMO it's already more readable
>>> than JSON regardless of whether or not values are quoted, simpl
On 9 June 2010 19:50, Robert Haas wrote:
> After thinking about this further, I think I'd still like to take one
> more crack at fixing this without quoting absolutely everything. I
> argued against this feature, but we decided to take it, and it seems
> that one of the major arguments that is be
On 9 June 2010 14:14, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 8:46 AM, Dean Rasheed wrote:
>> On 9 June 2010 03:48, Robert Haas wrote:
>>> please test.
>>
>> Well your patch definitely fixes my original bug, and AFAICT always
>> produces valid YAML output
On 9 June 2010 17:52, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
Why not? Surely we can restrict EXPLAIN's set of key names to be safe.
>>
>>> It seems to me that it would be easy for a
On 9 June 2010 17:25, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
>>> Why not? Surely we can restrict EXPLAIN's set of key names to be safe.
>
>> It seems to me that it would be easy for a future patch to break this
>> by accident.
>
> Really? What
On 9 June 2010 16:05, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 11:03 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, Jun 9, 2010 at 9:35 AM, Dean Rasheed
>>> wrote:
>>>>> Does anyone care that Alias will sometimes be a string, and somet
On 9 June 2010 03:48, Robert Haas wrote:
> please test.
Well your patch definitely fixes my original bug, and AFAICT always
produces valid YAML output now. I've only found one case where a
particular parser has difficulty parsing the output, and you'd have to
write a pretty perverse query to hit
On 9 June 2010 12:32, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 7:23 AM, Dean Rasheed wrote:
>> On 9 June 2010 12:07, Robert Haas wrote:
>>> On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed
>>> wrote:
>>>> On 9 June 2010 03:48, Robert Haas wrote:
>
On 9 June 2010 12:07, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed wrote:
>> On 9 June 2010 03:48, Robert Haas wrote:
>>> Er, I should also say, thanks for the report, and please test. I am
>>> definitely not an expert on YAML.
>>>
&g
On 9 June 2010 07:58, Dean Rasheed wrote:
> I prefer my patch - but then I suppose I would say that :-)
>
Seriously though, I can think of a number of good arguments in favour
of the "quote all string values unconditionally" approach:
- It's the simplest, least obtrusive fi
On 9 June 2010 03:48, Robert Haas wrote:
> Er, I should also say, thanks for the report, and please test. I am
> definitely not an expert on YAML.
>
I'm not an expert on YAML either, but I don't think this works (at
least it breaks against the online YAML parser here:
http://yaml-online-parser.a
On 7 June 2010 15:56, Tom Lane wrote:
> "Greg Sabino Mullane" writes:
>> I don't think the above would be particularly hard to implement myself,
>> but if it becomes a really big deal, we can certainly punt by simply
>> quoting anything containing an indicator (the special characters above).
>
>
Testing 9.0 beta, I found that EXPLAINing certain queries in YAML
format will produce invalid YAML, for example:
explain (format yaml) select * from foo where str_val = 'a: b';
The problem in this case is that a colon followed by whitespace is not
allowed in an unquoted plain YAML string because
2009/8/11 Tom Lane :
> Anyway it's looking like a slightly nontrivial project. Maybe we should
> just rephrase the error message Hubert is complaining about.
>
Yeah, I can't think of any simple way of distinguishing the 2 error
conditions in that code. Perhaps adding a suitable hint would help, a
2009/8/11 hubert depesz lubaczewski :
> While testing deferred unique constraints I found this:
>
> # CREATE TABLE test (
> i INT4 PRIMARY KEY
> );
> NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "test_pkey"
> for table "test"
> CREATE TABLE
>
> # set constraints test_pkey defe
The following bug has been logged online:
Bug reference: 4434
Logged by: Dean Rasheed
Email address: [EMAIL PROTECTED]
PostgreSQL version: 8.3
Operating system: SuSE 10.3 64-bit
Description:Error inserting into view - unrecognized node type: 313
Details:
I&#
28 matches
Mail list logo
