On Fri, Oct 14, 2011 at 07:36:32PM +0100, Peter Geoghegan wrote:
> This evening, David Fetter described a problem to me that he was
> having building the Twitter FDW. It transpired that it was down to its
> dependence on an #include that was recently judged to be
> redundant.This seems like another
On Fri, Oct 14, 2011 at 11:12 AM, Robert Haas wrote:
> On Wed, Oct 12, 2011 at 10:20 PM, Josh Kupershmidt wrote:
>>> On the third hand, Josh's previous batch of changes to clean up
>>> psql's behavior in this area are clearly a huge improvement: you can
>>> now display the comment for nearly anyt
On Sun, Oct 16, 2011 at 8:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> I previously floated the idea of using a new keyword, possibly LET,
>> for this, like this:
>
>> LET var = value [, ...] IN query
>
>> I'm not sure if anyone bought it, but I'll run it up the flagpole
>> again and see if an
On 10/16/2011 08:59 PM, Tom Lane wrote:
Robert Haas writes:
I previously floated the idea of using a new keyword, possibly LET,
for this, like this:
LET var = value [, ...] IN query
I'm not sure if anyone bought it, but I'll run it up the flagpole
again and see if anyone salutes. I tend to a
Robert Haas writes:
> I previously floated the idea of using a new keyword, possibly LET,
> for this, like this:
> LET var = value [, ...] IN query
> I'm not sure if anyone bought it, but I'll run it up the flagpole
> again and see if anyone salutes. I tend to agree with the idea that
> SET LOC
On Sun, Oct 16, 2011 at 4:58 PM, Tom Lane wrote:
> Dimitri Fontaine writes:
>> Now that you mention it, the following might actually already work:
>
>> WITH settings AS (
>> SELECT set_config('timezone', 'Europe/Amsterdam', t),
>> set_config('work_mem', '1 GB', t)
>> ),
>> fo
2011/10/17 Greg Stark :
> On Fri, Oct 14, 2011 at 9:32 PM, Tom Lane wrote:
>> We could hack around this by adding more columns to the result so that
>> an index-only scan doesn't work. But I wonder whether it wouldn't be
>> smarter to add ORDER BY clauses to the window function calls. I've been
CORRESPONDING clause take 2
After realizing that modifying prepunion.c to include a custom subquery
is not easy(incomprehensible to me) as it sounds and turning into a
hassle after making several uninformed changes, I decided to go with
modifying analyze.c.
The incomprehensible part is constructi
2011/10/17 Tom Lane :
> Hitoshi Harada writes:
>> 2011/10/15 Tom Lane :
>>> I can't recall whether there was some good reason for underspecifying
>>> these test queries. It looks like all the problematic ones were added in
>>> commit ec4be2ee6827b6bd85e0813c7a8993cfbb0e6fa7 "Extend the set of fra
Florian Pflug writes:
> ... reading those parts again, I realize the it says "When ORDER BY is omitted
> the *default* frame consists ... ", and that the second quote is followed
> by a footnote which says
> There are options to define the window frame in other ways, but this
> tutorial
> do
On Oct17, 2011, at 00:14 , Tom Lane wrote:
> Florian Pflug writes:
>> But some frame clauses (row 1 preceding, for example) have an effect despite
>> there being no ORDER BY, like here:
>
> Yeah, why did you expect differently? Without ORDER BY, all rows are
> peers in the frame ordering, so the
Florian Pflug writes:
> But some frame clauses (row 1 preceding, for example) have an effect despite
> there being no ORDER BY, like here:
Yeah, why did you expect differently? Without ORDER BY, all rows are
peers in the frame ordering, so there's no way for a RANGE spec to
select less than the
Hitoshi Harada writes:
> 2011/10/15 Tom Lane :
>> I can't recall whether there was some good reason for underspecifying
>> these test queries. It looks like all the problematic ones were added in
>> commit ec4be2ee6827b6bd85e0813c7a8993cfbb0e6fa7 "Extend the set of frame
>> options supported for
On Fri, 2011-10-07 at 12:54 +0400, Alexander Korotkov wrote:
> The first thing caught my eye in existing GiST code is idea of
> subtype_float. float8 has limited precision and can't respresent, for
> example, varlena values good enough. Even if we have large int8 value
> we can loose lower bits, b
Dimitri Fontaine writes:
> Now that you mention it, the following might actually already work:
> WITH settings AS (
>SELECT set_config('timezone', 'Europe/Amsterdam', t),
> set_config('work_mem', '1 GB', t)
> ),
> foo AS (
>SELECT â¦
> )
> INSERT INTO bar SELECT * FRO
Tom Lane writes:
> That looks pretty non-future-proof to me. WITH is a SQL-standard
> syntax, it's not an extension that we control.
Now that you mention it, the following might actually already work:
WITH settings AS (
SELECT set_config('timezone', 'Europe/Amsterdam', t),
set_con
Dimitri Fontaine writes:
> I think it would fit quite well within our extending of the WITH syntax.
> WITH
> work_mem = '1GB',
> timezone = 'Europe/Amsterdam',
> foo AS (
> SELECT something
> )
> SELECT toplevel FROM foo;
That looks pretty non-future-proof to me. WITH is a SQL-standar
Jeff Davis writes:
> On master, I see a minor test error (at least on my machine) as well as
> a diff. Patch attached.
Hmm, yeah, I forgot to fix this regression test when I added that DETAIL
line. However, I don't see the need for fooling with the lc_time value?
regards
Jan Urbański writes:
> this idea has cropped up last PGCon - the ability to set GUC variables
> for the duration of a single query. It would work by setting the GUCs
> for the duration of the query and setting them back to what they were
> after it has terminated. By "setting them back" I mean res
On Oct16, 2011, at 20:04 , Greg Stark wrote:
> On Fri, Oct 14, 2011 at 9:32 PM, Tom Lane wrote:
>> We could hack around this by adding more columns to the result so that
>> an index-only scan doesn't work. But I wonder whether it wouldn't be
>> smarter to add ORDER BY clauses to the window functi
Florian Pflug writes:
> On Oct16, 2011, at 19:09 , Tom Lane wrote:
>> That doesn't seem like the same thing at all, because the indexed column
>> is on different sides of the expression in the two cases. The situation
>> that I'm worried about is "indexedcolumn op ANY(arrayconstant)", and
>> what
Greg Stark writes:
> On Fri, Oct 14, 2011 at 4:29 PM, Tom Lane wrote:
>> Right. I think this one falls into my class #2, ie, we have no idea how
>> to implement it usefully. Doesn't (necessarily) mean that the core
>> concept is without merit.
> Hm. given that we have an implementation I would
On Oct16, 2011, at 19:09 , Tom Lane wrote:
> Florian Pflug writes:
>> On Oct15, 2011, at 20:58 , Tom Lane wrote:
>>> So, at least as far as btrees are concerned, it seems like I implemented
>>> the ScalarArrayOpExpr logic at the wrong level and it ought to be pushed
>>> down into the index AM. Th
On Fri, Oct 14, 2011 at 9:32 PM, Tom Lane wrote:
> We could hack around this by adding more columns to the result so that
> an index-only scan doesn't work. But I wonder whether it wouldn't be
> smarter to add ORDER BY clauses to the window function calls. I've been
> known to argue against addi
On Fri, Oct 14, 2011 at 4:29 PM, Tom Lane wrote:
> Right. I think this one falls into my class #2, ie, we have no idea how
> to implement it usefully. Doesn't (necessarily) mean that the core
> concept is without merit.
Hm. given that we have an implementation I wouldn't say we have *no*
clue.
On master, I see a minor test error (at least on my machine) as well as
a diff. Patch attached.
Regards,
Jeff Davis
*** a/src/test/regress/expected/collate.linux.utf8.out
--- b/src/test/regress/expected/collate.linux.utf8.out
***
*** 395,401 SELECT relname FROM pg_class WH
Florian Pflug writes:
> On Oct15, 2011, at 20:58 , Tom Lane wrote:
>> So, at least as far as btrees are concerned, it seems like I implemented
>> the ScalarArrayOpExpr logic at the wrong level and it ought to be pushed
>> down into the index AM. The above rules seem pretty btree-specific, so
>> I
On Oct15, 2011, at 20:58 , Tom Lane wrote:
> So, at least as far as btrees are concerned, it seems like I implemented
> the ScalarArrayOpExpr logic at the wrong level and it ought to be pushed
> down into the index AM. The above rules seem pretty btree-specific, so
> I don't think that we ought to
On 16/10/11 17:49, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
>> this idea has cropped up last PGCon - the ability to set GUC variables
>> for the duration of a single query. It would work by setting the GUCs
>> for the duration of the query and setting them back to what they were
On 16 October 2011 16:44, Jan Urbański wrote:
> Hi,
>
> this idea has cropped up last PGCon - the ability to set GUC variables
> for the duration of a single query. It would work by setting the GUCs
> for the duration of the query and setting them back to what they were
> after it has terminated.
On Oct15, 2011, at 14:52 , Thomas Girault wrote:
> Alternatively, we could also set the alpha value before the query :
>
> SELECT set_alpha(0.1); SELECT age, young(age) FROM employees WHERE
> young(age);
That's certainly much safer.
> I would be very interested to know if there is smarter way to
=?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= writes:
> this idea has cropped up last PGCon - the ability to set GUC variables
> for the duration of a single query. It would work by setting the GUCs
> for the duration of the query and setting them back to what they were
> after it has terminated.
Doesn't SET
Hi,
this idea has cropped up last PGCon - the ability to set GUC variables
for the duration of a single query. It would work by setting the GUCs
for the duration of the query and setting them back to what they were
after it has terminated. By "setting them back" I mean respecting the
previously se
Noah Misch writes:
> On Sat, Oct 15, 2011 at 02:58:45PM -0400, Tom Lane wrote:
>> [algorithm for a regular index scan satisfying "key IN (...)"]
> Sounds sensible. The algorithm applies to more than ScalarArrayOpExpr; is it
> not the ability to handle an OR'ed list of ScanKey instead of an AND'e
Hi Robert,
I'm a bit confusing about this sentence.
> If you can make this work, I think it could be a pretty sweet plannner
> optimization even apart from the implications for security views.
> Consider a query of this form:
>
> A LEFT JOIN B LEFT JOIN C
>
> where B is a view defined as:
>
> B1
35 matches
Mail list logo
