he database can become inconsistent and will
need a lot more work than an index rebuild.
> Suggestions for refining this are welcome.
>
> --
> Peter Eisentraut http://www.2ndQuadrant.com/
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
ger qualify in the
database.
It could be argued that these are edge cases and not likely to be hit.
That's likely true for a lot of users. But for a user who hits this, their
database is going to be left in a mess.
--
Doug Doole
On Tue, Sep 6, 2016 at 8:37 AM Peter Eisentraut <
peter.eisentr
strcmp()/memcmp() was
never called for user data. (I don't know if the same can be said for
Postgres.) We found that very few places needed to be aware of values that
were equal but not identical. (Index and sort were the big two.)
Hopefully Postgres will be the same.
--
Doug Doole
d support for
every drop of ICU.)
On Wed, Sep 7, 2016 at 5:53 AM Peter Eisentraut <
peter.eisentr...@2ndquadrant.com> wrote:
> On 9/6/16 1:40 PM, Doug Doole wrote:
> > We carried the ICU version numbers around on our collation and locale
> > IDs (such as fr_FR%icu36) . The databas
the
latest and greatest? If not, any chance of getting the latest?
Going forward, I'd be happy to collaborate on our efforts.
- Doug Doole
Salesforce
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref
tackle that, is the posted proof-of-concept still the
latest and greatest? If not, any chance of getting the latest?
Going forward, I'd like to collaborate on our efforts if you're interested.
- Doug Doole
Salesforce
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
RU for
cache memory management of course).
With literal replacement, the cache entry is on the modified statement
text. Given the modified statement text and the compilation environment,
you're guaranteed to get the right plan entry.
On Tue, Apr 25, 2017 at 2:47 PM Andres Freund <and...@anarazel.de>
>
> (FWIW, on this list we don't do top-quotes)
>
I know. Forgot and just did "reply all". My bad.
It's not always that simple, at least in postgres, unless you disregard
> search_path. Consider e.g. cases like
>
> CREATE SCHEMA a;
> CREATE SCHEMA b;
> CREATE TABLE a.foobar(somecol int);
> SET
>
> A naive option would be to invalidate anything that depends on table or
> view *.FOOBAR. You could probably make it a bit smarter by also requiring
> that schema A appear in the path.
>
This has been rumbling around in my head. I wonder if you could solve this
problem by registering
When I did this in DB2, I didn't use the parser - it was too expensive. I
just tokenized the statement and used some simple rules to bypass the
invalid cases. For example, if I saw the tokens "ORDER" and "BY" then I'd
disallow replacement replacement until I hit the end of the current
subquery or
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
Applied clean and runs fine. Previous comments were
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:not tested
Looks good to me.
The new status of this patch is: Ready for
The following review has been posted through the commitfest application:
make installcheck-world: tested, passed
Implements feature: tested, passed
Spec compliant: not tested
Documentation:not tested
Code looks fine, but one niggly complaint at line 146 of the patch
13 matches
Mail list logo
