For others following along, Pavel Stehule reviewed this on a different thread:
http://www.postgresql.org/message-id/cafj8pravyuhv8x3feewasggvdcijogvlzsavd7rmwn9mw8r...@mail.gmail.com
On Tue, Aug 06, 2013 at 10:47:14AM +0200, Fabien wrote:
> Improve pgbench measurements & progress report
These cha
On Sat, Sep 21, 2013 at 7:18 AM, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 3:15 AM, Albe Laurenz
> wrote:
> > David Rowley wrote:
> >> I moved the source around and I've patched against it again. New patch
> attached.
> >
> > Thank you, marked as ready for committer.
>
> /*
> + * helper func
Peter,
* Peter Geoghegan (p...@heroku.com) wrote:
> Forgive me if I'm making a leap here, but it seems like what you're
> saying is that the semantics of upsert that one might naturally expect
> are *arguably* fundamentally impossible, because they entail
> potentially locking a row that isn't cur
* Josh Berkus (j...@agliodbs.com) wrote:
> Also, live vs. dead tuples doesn't tell me how much free *space* is
> available on pages.
I'm not really sure that you'd get much better from ANALYZE than you get
from tracking the inserted/updated/deleted tuples. Collecting that
information when VACUUM
On Tue, Sep 17, 2013 at 9:29 AM, Robert Haas wrote:
> On Sat, Sep 14, 2013 at 6:27 PM, Peter Geoghegan wrote:
>> Note that today there is no guarantee that the original waiter for a
>> duplicate-inserting xact to complete will be the first one to get a
>> second chance
> ProcLockWakeup() only wa
From: "Robert Haas"
On Thu, Sep 19, 2013 at 7:58 PM, Tatsuo Ishii
wrote:
What about limiting to use NCHAR with a database which has same
encoding or "compatible" encoding (on which the encoding conversion is
defined)? This way, NCHAR text can be automatically converted from
NCHAR to the databa
From: "Robert Haas"
I don't think that you'll be able to
get consensus around that path on this mailing list.
I agree that the fact we have both varchar and text feels like a wart.
Is that right? I don't feel varchar/text case is a wart. I think text was
introduced for a positive reason
From: "Martijn van Oosterhout"
As far as I can tell the whole reason for introducing NCHAR is to
support SHIFT-JIS, there hasn't been call for any other encodings, that
I can remember anyway.
Could you elaborate on this, giving some info sources?
So rather than this whole NCHAR thing, why n
From: "Valentine Gogichashvili"
the whole NCHAR appeared as hack for the systems, that did not have it
from
the beginning. It would not be needed, if all the text would be magically
stored in UNICODE or UTF from the beginning and idea of character would be
the same as an idea of a rune and not
From: "Tatsuo Ishii"
What about limiting to use NCHAR with a database which has same
encoding or "compatible" encoding (on which the encoding conversion is
defined)? This way, NCHAR text can be automatically converted from
NCHAR to the database encoding in the server side thus we can treat
NCHAR
On 09/20/2013 02:17 PM, Stephen Frost wrote:
>> No?
>
> Err, I thought that was one of the things like ANALYZE *did* collect
> through the 'live tuples' number?
Nope. "live tuples" is updated by the stats collector, NOT by analyze.
Also, live vs. dead tuples doesn't tell me how much free *space
Hello Mitsumasa,
In the general transaction situation, clients access for all records equally is
hard to happen. I think gaussian distribution access patterns are most of
transaction petterns in general. My patch realizes neary this access pattern.
That is great! I was just looking for someth
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> I've been tinkering with a number of table bloat checks, and it occurred
> to me that the problm is that these are all approximations based on
> overall gross statistics, and as such highly inaccurate.
Greg Smith and I discussed some improvements a
On Thu, Sep 19, 2013 at 7:43 AM, Andres Freund wrote:
>> More generally, the thing that bugs me about this approach is that
>> logical replication is not really special, but what you've done here
>> MAKES it special. There are plenty of other situations where we are
>> too aggressive about holding
KONDO Mitsumasa wrote:
> I create gaussinan distribution pgbench patch that can access
> records with gaussian frequency. And I submit this commit fest.
Thanks!
I have moved this to the Open CommitFest, though.
https://commitfest.postgresql.org/action/commitfest_view/open
You had accidentally
Here's the patch I propose to handle renegotiation cleanly. I noticed
in testing that SSL_renegotiate_pending() doesn't seem to actually work
--- if I throw an ereport(FATAL) at the point where I expect the
renegotiation to be complete, it always dies; even if I give it
megabytes of extra traffic
On 9/20/13 2:22 PM, Robert Haas wrote:
>>> I am not keen to introduce support for nchar and nvarchar as
>>> >> differently-named types with identical semantics.
>> >
>> > Similar examples already exist:
>> >
>> > - varchar and text: the only difference is the existence of explicit length
>> > limit
The file_fdw documentation for the OPTIONS clause references the COPY
command's documentation. In the case of COPY, the value for some options
(e.g. HEADER, OIDS, ...) is optional. While the file_fdw documentation
makes no mention of it, the values for all options are required.
Attached is a pat
Hello Robert,
- some concerns have been raised that it breaks pg_sleep(TEXT)
which currently works thanks to the implicit TEXT -> INT cast.
I would suggest to add pg_sleep(TEXT) explicitely, like:
CREATE FUNCTION pg_sleep(TEXT) RETURNS VOID VOLATILE STRICT AS
$$ select pg_sle
On Fri, Sep 20, 2013 at 7:59 AM, Fabien COELHO wrote:
> - the new function is *not* tested anywhere!
>
>I would suggest simply to replace some pg_sleep(int) instances
>by corresponding pg_sleep(interval) instances in the non
>regression tests.
>
> - some concerns have been raised tha
On Thu, Sep 19, 2013 at 6:19 PM, Andres Freund wrote:
> On 2013-09-19 14:57:53 -0400, Robert Haas wrote:
>> On Tue, Sep 17, 2013 at 6:56 PM, Andres Freund
>> wrote:
>> > I think that ship has long since sailed. postgresql.conf has allowed
>> > foo.bar style GUCs via custom_variable_classes for a
Hackers,
I've been tinkering with a number of table bloat checks, and it occurred
to me that the problm is that these are all approximations based on
overall gross statistics, and as such highly inaccurate.
It seems like would could have ANALYZE, while sampling from the table,
also check the amou
On Fri, Sep 20, 2013 at 3:15 AM, Albe Laurenz wrote:
> David Rowley wrote:
>> I moved the source around and I've patched against it again. New patch
>> attached.
>
> Thank you, marked as ready for committer.
/*
+ * helper function for processing the format string in
+ * log_line_prefix()
+ * Th
On 09/20/2013 11:59 AM, Josh Berkus wrote:
Hackers,
I've been tinkering with a number of table bloat checks, and it occurred
to me that the problm is that these are all approximations based on
overall gross statistics, and as such highly inaccurate.
It seems like would could have ANALYZE, whi
On Thu, Sep 19, 2013 at 6:42 PM, MauMau wrote:
> National character types support may be important to some potential users of
> PostgreSQL and the popularity of PostgreSQL, not me. That's why national
> character support is listed in the PostgreSQL TODO wiki. We might be losing
> potential users
Dimitri Fontaine escribió:
> My understanding is that if you choose citext then you don't care at all
> about the case, so that the two relations actually yield the same
> results for the right definition of "same" here: the citext one.
For the record, I don't think citext means that the user doe
On Thu, Sep 19, 2013 at 7:58 PM, Tatsuo Ishii wrote:
> What about limiting to use NCHAR with a database which has same
> encoding or "compatible" encoding (on which the encoding conversion is
> defined)? This way, NCHAR text can be automatically converted from
> NCHAR to the database encoding in t
On 09/20/2013 08:38 AM, Kevin Grittner wrote:
Did you look at the record_eq and record_cmp functions which exist
before this patch? Is there a reason we should do it one way for the
default operators and another way for this alternative?
Do you think we should change record_eq and record_cmp t
Hi,
IMO it's a bug if S_UNLOCK is a not a compiler barrier.
Moreover for volatile remember:
https://www.securecoding.cert.org/confluence/display/seccode/DCL17-C.+Beware+of+miscompiled+volatile-qualified+variables
Who is double checking compiler output? :)
regards
Didier
On Fri, Sep 20, 2013
On 09/19/2013 04:16 PM, Tatsuo Ishii wrote:
> Hi,
>
> I'm Looking for information on our elephant: especially how/why we
> chose elephant as our mascot.
What I've been told:
Our first logo was one Jan designed, which was a elephant in a diamond.
While the idea was nice, it looked terrible, so w
Robert,
> It probably has to do with the CASE stakind stuff in the definition of
> the pg_stats view. Try \d+ pg_stats to see what I mean.
Ok, if this is not a known bug, I'll see if I can work up a fix. No
promises, given the hairyness ...
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexpe
On 09/19/2013 02:55 PM, Mike Blackwell wrote:
> Interesting. Is this a 9.3 issue? I ran the above against my 9.2.4 server
> and got no rows in pg_stats. Did I miss something?
Yeah, that was on 9.3. I think the issue on 9.2 is the same, it just
expresses differently.
--
Josh Berkus
PostgreSQL
Hi
On Fri, Sep 20, 2013 at 5:11 PM, Andres Freund wrote:
> On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
> > I think we should go through the various implementations and make sure
> > they are actual compiler barriers and then change the documented policy.
>
> From a quick look
> * S_UNLOCK
On Fri, Sep 20, 2013 at 11:51 AM, Andres Freund wrote:
> On 2013-09-20 11:30:26 -0400, Robert Haas wrote:
>> On Thu, Sep 19, 2013 at 6:59 PM, Andres Freund
>> wrote:
>> > The reason I suggested keeping track of the xids of unremovable tuples
>> > is that the current logic doesn't handle that at
On 2013-09-20 11:30:26 -0400, Robert Haas wrote:
> On Thu, Sep 19, 2013 at 6:59 PM, Andres Freund wrote:
> > The reason I suggested keeping track of the xids of unremovable tuples
> > is that the current logic doesn't handle that at all. We just
> > unconditionally set n_dead_tuples to zero after
2013/9/20 Alvaro Herrera
> Pavel Stehule escribió:
>
> > PL/pgSQL had a ADA completeness, uniformity and beauty newer. But it is
> not
> > too bad, and one new specialized statement doesn't kill us. A proposed
> > functionality is often used and we have not tools (macros) how to
> implement
> > i
Pavel Stehule escribió:
> PL/pgSQL had a ADA completeness, uniformity and beauty newer. But it is not
> too bad, and one new specialized statement doesn't kill us. A proposed
> functionality is often used and we have not tools (macros) how to implement
> it simply.
>
> we support a conditions for
On 2013-09-20 16:47:24 +0200, Andres Freund wrote:
> I think we should go through the various implementations and make sure
> they are actual compiler barriers and then change the documented policy.
>From a quick look
* S_UNLOCK for PPC isn't a compiler barrier
* S_UNLOCK for MIPS isn't a compiler
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-09-20 11:05:06 -0400, Stephen Frost wrote:
> > Sure; my thinking was going back to what Hannu had suggested where we
> > have a mechanism to see if the value was updated (using xmin or similar)
> > and then update it in the mat view in that
On Thu, Sep 19, 2013 at 6:59 PM, Andres Freund wrote:
> The reason I suggested keeping track of the xids of unremovable tuples
> is that the current logic doesn't handle that at all. We just
> unconditionally set n_dead_tuples to zero after a vacuum even if not a
> single row could actually be cle
* Kevin Grittner (kgri...@ymail.com) wrote:
> Stephen Frost wrote:
> > You mean 'at the time of the incremental refresh', right? Yet that may
> > or may not match running that query directly by an end-user as the plan
> > that a user might get for the entire query could be different than what
> >
On 2013-09-20 11:05:06 -0400, Stephen Frost wrote:
> * Andres Freund (and...@2ndquadrant.com) wrote:
> > On 2013-09-20 10:51:46 -0400, Stephen Frost wrote:
> > > I'm trying to figure out why that's a perfectly acceptable solution for
> > > users running views with GROUP BYs, but apparently it isn't
Andres Freund escribió:
> Hi,
>
> On 2013-09-19 14:42:19 +0300, Heikki Linnakangas wrote:
> > On 18.09.2013 16:22, Andres Freund wrote:
> > >* Why can we do a GetOldestXmin(allDbs = false) in
> > > BeginXidLSNRangeSwitch()?
> >
> > Looks like a bug. I think I got the arguments backwards, was su
* Andres Freund (and...@2ndquadrant.com) wrote:
> On 2013-09-20 10:51:46 -0400, Stephen Frost wrote:
> > I'm trying to figure out why that's a perfectly acceptable solution for
> > users running views with GROUP BYs, but apparently it isn't sufficient
> > for mat views?
>
> Err, because users wrot
Stephen Frost wrote:
> * Kevin Grittner (kgri...@ymail.com) wrote:
>> The result of this is that with the patch, an incremental refresh
>> of a matview will always match what the query returned at the time
>> it was run (there is no *correctness* problem) but if someone uses
>> a query with non-de
On 2013-09-20 10:51:46 -0400, Stephen Frost wrote:
> I'm trying to figure out why that's a perfectly acceptable solution for
> users running views with GROUP BYs, but apparently it isn't sufficient
> for mat views?
Err, because users wrote a GROUP BY? They haven't (neccessarily) in the
cases of th
* Kevin Grittner (kgri...@ymail.com) wrote:
> The result of this is that with the patch, an incremental refresh
> of a matview will always match what the query returned at the time
> it was run (there is no *correctness* problem) but if someone uses
> a query with non-deterministic results they may
On 2013-09-20 08:54:26 -0400, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 8:40 AM, Andres Freund wrote:
> > On 2013-09-20 08:32:29 -0400, Robert Haas wrote:
> >> Personally, I think the biggest change that would help here is to
> >> mandate that spinlock operations serve as compiler fences. That
Stephen Frost wrote:
> On Friday, September 20, 2013, Kevin Grittner wrote:
>> Stephen Frost wrote:
>>
>>> The issue here is that we're trying to make the mat view look
>>> like what the query would do when run at the same time, which
>>> is a bit of a losing battle, imv.
>>
>> If we're not doin
On 20 September 2013 11:29, Samrat Revagade wrote:
>>
>>
>> > Okay, are you adding this to the september commitfest?
>> >
>>
>> OK, I've done that. I think that it's too late for 9.3.
>>
>
>
> +1 for idea.
>
> I have tested patch and got surprising results with Cent-OS
> Patch is working fine for
Andres Freund wrote:
>> On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
>>> When a tuple is predicate-locked, the key of the lock is ctid+xmin.
>>> However, when a tuple is frozen, its xmin is changed to FrozenXid. That
>>> effectively
>>> invalidates any predicate lock on the tuple, as ch
On Friday, September 20, 2013, Kevin Grittner wrote:
> Stephen Frost > wrote:
>
> > The issue here is that we're trying to make the mat view look
> > like what the query would do when run at the same time, which is
> > a bit of a losing battle, imv.
>
> If we're not doing that, I don't see the poi
Stephen Frost wrote:
> The issue here is that we're trying to make the mat view look
> like what the query would do when run at the same time, which is
> a bit of a losing battle, imv.
If we're not doing that, I don't see the point of matviews.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
On Fri, Sep 20, 2013 at 7:17 PM, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 9:43 AM, Amit Kapila wrote:
>>Handling for OID is not clear, shall we allow it or not in check
>> constraint?
>>In my current patch OID will not be allowed in check constraint.
>
> I vote for allowing it.
Okay
Stephen Frost wrote:
> * Kevin Grittner (kgri...@ymail.com) wrote:
>> ... like
>> just refreshing a view so that the new contents are the same as
>> what you would see if you re-ran the query defining the matview.
>
> I've heard this notion a few times of wanting to make sure that what you
> get f
On Fri, Sep 20, 2013 at 9:43 AM, Amit Kapila wrote:
>Handling for OID is not clear, shall we allow it or not in check
> constraint?
>In my current patch OID will not be allowed in check constraint.
I vote for allowing it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Ent
Steve,
Thanks for providing a summary.
* Steve Singer (st...@ssinger.info) wrote:
> The arguments for this patch are
> * We want the materialized view to return the same value as would be
> returned if the query were executed directly. This not only means
> that the values should be the same a
On Fri, Sep 20, 2013 at 5:53 PM, Robert Haas wrote:
> On Fri, Sep 20, 2013 at 3:41 AM, Amit Kapila wrote:
>> On Fri, Sep 20, 2013 at 12:57 PM, Amit Kapila
>> wrote:
>>> On Thu, Sep 19, 2013 at 10:28 PM, Robert Haas wrote:
>> Marking this as Ready for committer.
>
> Thanks a ton for
Robert Haas escribió:
> On Sun, Sep 15, 2013 at 10:51 AM, Peter Eisentraut wrote:
> > On Sun, 2013-09-15 at 16:09 +0200, Dimitri Fontaine wrote:
> >> Peter Eisentraut writes:
> >> > It shouldn't be in the commit fest if it has no patch.
> >>
> >> What should I do if my goal is to get community co
On Fri, Sep 20, 2013 at 3:40 PM, Sameer Thakur wrote:
>
>
>
>
>>>
>> >Attached patch combines documentation patch and source-code patch.
>>
>
> I have had a stab at reviewing the documentation. Have a look.
>
>
Thanks.
Attached patch implements suggestions in documentation.
But comments from Fujii
On 09/20/2013 01:59 PM, Robert Haas wrote:
> The other part of the problem is that the language isn't designed from
> the beginning to be extensible. In Perl, for example, they chose to
> mark variables with a leading $, @, or % and functions with a leading
> &. That last marking has largely fall
2013/9/20 Robert Haas
> On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja wrote:
> >> The issue of how this is spelled is somewhat secondary for me. I
> >> think ASSERT is probably as good as anything. But let's not kid
> >> ourselves: even reserving this word only in PL/pgsql WILL break things
On Fri, Sep 20, 2013 at 8:40 AM, Andres Freund wrote:
> On 2013-09-20 08:32:29 -0400, Robert Haas wrote:
>> Personally, I think the biggest change that would help here is to
>> mandate that spinlock operations serve as compiler fences. That would
>> eliminate the need for scads of volatile refere
On 2013-09-20 14:35:31 +0200, Dimitri Fontaine wrote:
> Robert Haas writes:
> > So... our usual comma-separated GUC syntax? Empty means no extra
> > places to search.
+1.
> The only advantage of using an initdb place would have been the
> opportunity to actually register modules and WAL log tha
Hi,
I agree with most of what you said - I think that's a littlebit too much
change for too little benefit.
On 2013-09-20 08:32:29 -0400, Robert Haas wrote:
> Personally, I think the biggest change that would help here is to
> mandate that spinlock operations serve as compiler fences. That would
Steve Singer wrote:
> On 09/12/2013 06:27 PM, Kevin Grittner wrote:
>> Attached is a patch for a bit of infrastructure I believe to be
>> necessary for correct behavior of REFRESH MATERIALIZED VIEW
>> CONCURRENTLY as well as incremental maintenance of matviews.
>
> Here is attempt at a review of t
Robert Haas writes:
> So... our usual comma-separated GUC syntax? Empty means no extra
> places to search.
Sounds pretty good to me.
The only advantage of using an initdb place would have been the
opportunity to actually register modules and WAL log that step so that
the standby pg_modules dire
On Thu, Sep 19, 2013 at 6:27 PM, Ants Aasma wrote:
> I'm tackling similar issues in my patch. What I'm thinking is that we should
> change our existing supposedly atomic accesses to be more explicit and make
> the API compatible with C11 atomics[1]. For now I think the changes should be
> somethin
* Kevin Grittner (kgri...@ymail.com) wrote:
> ... like
> just refreshing a view so that the new contents are the same as
> what you would see if you re-ran the query defining the matview.
I've heard this notion a few times of wanting to make sure that what you
get from running the query matches th
On Fri, Sep 20, 2013 at 3:41 AM, Amit Kapila wrote:
> On Fri, Sep 20, 2013 at 12:57 PM, Amit Kapila wrote:
>> On Thu, Sep 19, 2013 at 10:28 PM, Robert Haas wrote:
> Marking this as Ready for committer.
Thanks a ton for reviewing the patch.
>>>
>>> I rewrote the comments for this pa
On Fri, Sep 20, 2013 at 8:10 AM, Andres Freund wrote:
> On 2013-09-20 08:06:56 -0400, Robert Haas wrote:
>> On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund
>> wrote:
>> > Because I want to specify multiple paths. E.g. one with modules for a
>> > specific postgres version, one for the cluster and
On 2013-09-20 08:06:56 -0400, Robert Haas wrote:
> On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund wrote:
> > Because I want to specify multiple paths. E.g. one with modules for a
> > specific postgres version, one for the cluster and one for my
> > development directory.
> > Now we could recursive
On Thu, Sep 19, 2013 at 5:54 PM, Andres Freund wrote:
> On 2013-09-19 22:56:52 +0200, Dimitri Fontaine wrote:
>> Robert Haas writes:
>> >> I think I'd prefer a GUC that allows specifying multiple directories
>> >> that are searched in order to a single symlinked directory.
>> >
>> > Why?
>> >
>>
On Fri, Sep 20, 2013 at 6:24 AM, Marko Tiikkaja wrote:
>> The issue of how this is spelled is somewhat secondary for me. I
>> think ASSERT is probably as good as anything. But let's not kid
>> ourselves: even reserving this word only in PL/pgsql WILL break things
>> for some users, and there are
Here is a review of the pg_sleep(INTERVAL) patch version 1:
- patch applies cleanly on current head
- the function documentation is updated and clear
- the function definition relies on a SQL function
to call the underlying pg_sleep(INT) function
I'm fine with this, especially as if s
On 2013-09-20 13:53:04 +0200, Andres Freund wrote:
> Hi,
>
>
> On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
> > When a tuple is predicate-locked, the key of the lock is ctid+xmin. However,
> > when a tuple is frozen, its xmin is changed to FrozenXid. That effectively
> > invalidates an
Hi,
On 2013-09-20 13:55:36 +0300, Heikki Linnakangas wrote:
> When a tuple is predicate-locked, the key of the lock is ctid+xmin. However,
> when a tuple is frozen, its xmin is changed to FrozenXid. That effectively
> invalidates any predicate lock on the tuple, as checking for a lock on the
> sa
Hi,
On 2013-09-19 11:44:34 -0400, Robert Haas wrote:
> On Wed, Sep 18, 2013 at 1:42 PM, Andres Freund wrote:
> >> --- /dev/null
> >> +++ b/src/backend/storage/ipc/dsm.c
> >> +#define PG_DYNSHMEM_STATE_FILE PG_DYNSHMEM_DIR
> >> "/state"
> >> +#define PG_DYNSHMEM_NEW_STATE_
Hi,
Prompted by Andres Freund's comments on my Freezing without Write I/O
patch, I realized that there's there's an existing bug in the way
predicate locking handles freezing (or rather, it doesn't handle it).
When a tuple is predicate-locked, the key of the lock is ctid+xmin.
However, when
Hi,
On 2013-09-19 12:05:35 -0400, Robert Haas wrote:
> No question. I'm not saying that that optimization shouldn't go in
> right after the main patch does, but IMHO right now there are too many
> things going in the 0004 patch to discuss them all simultaneously.
> I'd like to find a way of split
>
> > Okay, are you adding this to the september commitfest?
> >
>
> OK, I've done that. I think that it's too late for 9.3.
>
>
+1 for idea.
I have tested patch and got surprising results with Cent-OS
Patch is working fine for Cent-OS 6.2 and RHEL 6.3
But is is giving problem on Cent-OS 6.3 (ta
On 9/19/13 9:09 PM, Robert Haas wrote:
Personally, I'm pretty skeptical about the value of adding dedicated
syntax for this. I mean, I'll be the first to admit that PL/pgsql is
a clunky and awkward language. But somebody's always proposing
something that they think will make it better, and I fe
On Thu, Sep 19, 2013 at 06:31:38PM -0400, Steve Singer wrote:
> I think there is agreement that better (as in more obscure)
> operators than === and !== need to be picked and we need to find a
> place in the user-docs to warn users of the behaviour of this
> operators. Hannu has proposed
>
> *=
On 9/20/13 12:09 PM, Amit Khandekar wrote:
On 16 September 2013 03:43, Marko Tiikkaja wrote:
I think it would be extremely surprising if a command like that got
optimized away based on a GUC, so I don't think that would be a good idea.
In pl_gram.y, in the rule stmt_raise, determine that thi
>>
> >Attached patch combines documentation patch and source-code patch.
>
I have had a stab at reviewing the documentation. Have a look.
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1749,6 +1749,50 @@ include 'filename'
+
+ synchronous_transfer
On Fri, Sep 20, 2013 at 08:58:53AM +0900, Tatsuo Ishii wrote:
> For example, "CREATE TABLE t1(t NCHAR(10))" will succeed if NCHAR is
> UTF-8 and database encoding is UTF-8. Even succeed if NCHAR is
> SHIFT-JIS and database encoding is UTF-8 because there is a conversion
> between UTF-8 and SHIFT-JI
On 16 September 2013 03:43, Marko Tiikkaja wrote:
> On 2013-09-15 23:23, Jaime Casanova wrote:
>
>> If using ASSERT as keyword is not acceptable, not that i agree but in
>> case.
>> What about using RAISE EXCEPTION WHEN (condition)
>>
>
> I was going to suggest the same idea: Extend RAISE syntax
On Fri, Sep 20, 2013 at 1:11 AM, Daniel Farina wrote:
> I think the n-call underestimation propagation may not be quite precise for
> various detailed reasons (having to do with 'sticky' queries) and to make it
> precise is probably more work than it's worth. And, on more reflection, I'm
> also h
On 09/19/2013 11:40 PM, Dimitri Fontaine wrote:
> Vik Fearing writes:
>> I don't know if this has been discussed before, a cursory search of the
>> archives didn't turn up anything interesting. I perhaps didn't put in
>> the right keywords.
> For others not to spend too much time on this: it seem
On Fri, Sep 20, 2013 at 12:57 PM, Amit Kapila wrote:
> On Thu, Sep 19, 2013 at 10:28 PM, Robert Haas wrote:
Marking this as Ready for committer.
>>>
>>> Thanks a ton for reviewing the patch.
>>
>> I rewrote the comments for this patch and fixed the incorrect
>> formatting in parse_relation.c
On Thu, Sep 19, 2013 at 10:28 PM, Robert Haas wrote:
>>> Marking this as Ready for committer.
>>
>> Thanks a ton for reviewing the patch.
>
> I rewrote the comments for this patch and fixed the incorrect
> formatting in parse_relation.c. It used spaces instead of tabs, which
> is why if you look
David Rowley wrote:
> I moved the source around and I've patched against it again. New patch
> attached.
Thank you, marked as ready for committer.
Yours,
Laurenz Albe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgres
92 matches
Mail list logo
