Hi guys,
I noticed the following item under "Observe the following
incompatibilities" in the 8.4 release notes (E.1.2.4.1.)
* Require to_timestamp() input to match meridian (AM/PM) and era
(BC/AD) format designations with respect to presence of periods
(Brendan Jurd)
For example, input val
2009/4/19 Tom Lane
> Heikki Linnakangas writes:
> > Ian Barwick wrote:
> >> Note I'm not sure whether this is a bug, or whether the assumption
> >> made for the original query (that the row order returned by the
> >> subquery would be carried over to the main part of the query) is
> >> incorrect
Heikki Linnakangas wrote:
Tom Lane wrote:
Heikki Linnakangas writes:
That way you could
grant SELECT_FOR_SHARE permission on a table to let people insert rows
into other tables that have a foreign key reference to it, without
having to grant UPDATE permission.
... but this argument for it is
Tom Lane wrote:
Greg Stark writes:
...
I suppose if we had explain-to-a-table then we could run explain and
then run an sql query to verify the specific properties we were
looking for.
A similar thing could be done with xml if we had powerful enough xml
predicates but we have a lot more sql
On Sat, Apr 18, 2009 at 11:19 PM, Grzegorz Jaskiewicz
wrote:
> This is a really funny one, because people naturally expect UNION [ALL] to
> stay in the same order. Unlike the table, order here cannot change by
> inserts/updates, etc.
> I am sure many, even well experienced will stumble upon that o
On 18 Apr 2009, at 22:22, Tom Lane wrote:
This is mentioned in the release notes, but I suppose we'd better
promote it to the "observe the following incompatibilities" list...
This is a really funny one, because people naturally expect UNION
[ALL] to stay in the same order. Unlike the tabl
Greg Stark writes:
> On Sat, Apr 18, 2009 at 1:32 PM, Tom Lane wrote:
>> I'm inclined to think that some sort of fuzzy examination of EXPLAIN
>> output (in this example, "are there constant-comparison conditions in
>> the relation scans?") might do the job, but I'm not sure how we'd
>> go about t
Heikki Linnakangas writes:
> Ian Barwick wrote:
>> Note I'm not sure whether this is a bug, or whether the assumption
>> made for the original query (that the row order returned by the
>> subquery would be carried over to the main part of the query) is
>> incorrect but just happened to work as exp
Ian Barwick wrote:
Workaround / solution to produce consistent results is to move the
"ORDER BY 1" to the main SELECT clause:
SELECT 1 AS id , 2 AS tmpl_id
WHERE FALSE
UNION
SELECT * FROM
(SELECT 2 AS id, 96 AS tmpl_id
UNION
SELECT 3 AS id, 101 AS t
Ian Barwick wrote:
Note I'm not sure whether this is a bug, or whether the assumption
made for the original query (that the row order returned by the
subquery would be carried over to the main part of the query) is
incorrect but just happened to work as expected pre-8.4.
The latter. Without an
Hi
The following query is distilled down from a real production query for
ease of reproduction:
SELECT 1 AS id , 2 AS tmpl_id
WHERE FALSE -- (in production, only rarely will this clause return a row)
UNION
SELECT * FROM
(SELECT 2 AS id, 96 AS tmpl_id
UNION
2009/4/18 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/11 Tom Lane :
>>> No, I was complaining that a hook right there is useless and expensive.
>>> transformExpr() is executed multiple times per query, potentially a very
>>> large number of times per query; so even testing to see if a hook exists
Tom Lane wrote:
Heikki Linnakangas writes:
That way you could
grant SELECT_FOR_SHARE permission on a table to let people insert rows
into other tables that have a foreign key reference to it, without
having to grant UPDATE permission.
... but this argument for it is utter nonsense. FKs are n
On Sat, Apr 18, 2009 at 1:32 PM, Tom Lane wrote:
> I'm inclined to think that some sort of fuzzy examination of EXPLAIN
> output (in this example, "are there constant-comparison conditions in
> the relation scans?") might do the job, but I'm not sure how we'd
> go about that.
If we just removed a
Andrew Dunstan writes:
> Hannu Krosing wrote:
>> Can't we make first cut at it by just running with timings on and then
>> compare ratios of running times - maybe with 2-3X tolerance - to catch
>> most obvious regressions ?
> The current regression tests are a series of yes/no answers to this
>
On 4/18/09, Tom Lane wrote:
> Sam Mason writes:
> > On Fri, Apr 17, 2009 at 07:01:47PM +0200, Martijn van Oosterhout wrote:
> >> On Fri, Apr 17, 2009 at 07:07:31PM +0300, Marko Kreen wrote:
> >>> Btw, is there any good reason why we don't reject \000, \x00
> >>> in text strings?
> >>
> >> W
Pavel Stehule writes:
> 2009/4/11 Tom Lane :
>> No, I was complaining that a hook right there is useless and expensive.
>> transformExpr() is executed multiple times per query, potentially a very
>> large number of times per query; so even testing to see if a hook exists
>> is not a negligible cos
Hannu Krosing wrote:
On Wed, 2009-04-15 at 18:04 -0400, Tom Lane wrote:
Simon Riggs writes:
I've always been scared to ask this question, in case the answer is No,
but: Do we have a set of regression tests for the optimizer anywhere?
Nothing beyond what is in the standard tes
Heikki Linnakangas writes:
> IMHO the only sane change would be to introduce a new
> ACL_SELECT_FOR_SHARE permission for SELECT FOR SHARE.
This might be worth doing ...
> That way you could
> grant SELECT_FOR_SHARE permission on a table to let people insert rows
> into other tables that have a f
Hello
2009/4/11 Tom Lane :
> Pavel Stehule writes:
>> 2009/4/11 Tom Lane :
>>> Pavel Stehule writes:
I am sending small patch, that allows hooking transformation stage of
parser.
>>>
>>> Isn't this the exact same patch we rejected several months ago?
>
>> What I remember, You had some
On Wed, 2009-04-15 at 18:04 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > I've always been scared to ask this question, in case the answer is No,
> > but: Do we have a set of regression tests for the optimizer anywhere?
>
> Nothing beyond what is in the standard tests. While that's okay at
>
Here the patch to /src/interfaces/libpq/bcc32.mak attached improving
Borland C++ Compiler compatibility.
Issues described here:
http://pgolub.wordpress.com/2009/04/13/building-postgresql-client-library-using-borland-c-compiler-bcc-under-winxp/
This patch changes order of include folders placing
.
++
David Fetter wrote:
On Fri, Apr 17, 2009 at 01:01:39PM -0400, Alvaro Herrera wrote:
David Fetter wrote:
Speaking of standard_conforming_strings, I know it's late, but if
we make it a requirement now, a lot of problems just go away.
Yes, it's inconvenient, but we're making lots of big chan
Here the patches to /src/include/libpq/libpq-be.h and
/src/interfaces/libpq/libpq-int.h attached improving
MinGW compatibility.
Issues described here:
http://pgolub.wordpress.com/2008/12/15/building-postgresql-client-library-using-mingw-under-winxp-sp3/
This patch adds missing includes with appro
Here the patch to /src/include/pg_config_os.h attached improving
Borland C++ Compiler compatibility.
Issues described here:
http://pgolub.wordpress.com/2009/04/13/building-postgresql-client-library-using-borland-c-compiler-bcc-under-winxp/
This patch defines missing constants needed by /port/dire
25 matches
Mail list logo
