On Thu, Jun 16, 2011 at 4:10 AM, Jaime Casanova wrote:
> On Wed, Jun 15, 2011 at 7:08 PM, Alvaro Herrera
> wrote:
>>
>> Yeah, nothing serious. Updated patch attached. The wording in the doc
>> changes could probably use some look over.
>>
>
> looks good to me... at least it compiles, and functi
On 18 June 2011 13:43, Alvaro Herrera wrote:
> Is this really a WIP patch? I'm playing a bit with it currently, seems
> fairly sane.
>
In this case, the WIP designation is meant to convey "warning: only
casual testing has beeen done". I tried it out with various
permutations of pg_hba.conf, and
Excerpts from Brendan Jurd's message of vie jun 17 19:31:41 -0400 2011:
> On 16 June 2011 00:22, Pavel Stehule wrote:
> > I try to apply your patch, but it is finished with some failed hinks.
> >
> > Please, can you refresh your patch
>
> Hi Pavel,
>
> Thanks for taking a look. I have attached
On 06/17/2011 01:05 PM, Tom Lane wrote:
> Peter Eisentraut writes:
>> Is this a bug fix that should be backpatched?
>
> I pinged Joe Conway about this. He is jetlagged from a trip to the Far
> East but promised to take care of it soon. I think we can wait for his
> review.
Sorry for the delay.
Bruce Momjian wrote:
>
> Wow, this is the first I am hearing GNU cp -i can return zero exit if it
> doesn't do the copy. I tested this on Ubuntu 10.04 using cp 7.4 and
> got:
>
> $ touch x y
> $ cp -i x y; echo $?
> cp: overwrite `y'? n
> 0
>
> I see the same on my anche
Andrew Dunstan wrote:
>
>
> On 06/17/2011 06:59 PM, Bruce Momjian wrote:
> >
> > (FYI, I think we would need to use PGPASSWORD for the password file
> > option, and we don't recommend PGPASSWORD use in our docs.)
> >
>
> er what?
>
> did you mean PGPASSFILE?
I meant the PGPASSWORD environment
On Fri, Jun 17, 2011 at 1:54 PM, David Fetter wrote:
> On Fri, Jun 17, 2011 at 09:57:13AM -0500, Jaime Casanova wrote:
>>
>> Are you still working on this? should we expect a new patch?
>
> Yes, sorry about that. I let work get on top of me. Will try for a
> new patch this evening.
>
ok... i wi
On 06/17/2011 06:59 PM, Bruce Momjian wrote:
(FYI, I think we would need to use PGPASSWORD for the password file
option, and we don't recommend PGPASSWORD use in our docs.)
er what?
did you mean PGPASSFILE?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresq
On 22 May 2011 07:27, Fabien COELHO wrote:
>
> Hello Tom,
>
>>> Add "AS EXPLICIT" to "CREATE CAST" This gives a name to the default case
>>> of "CREATE CAST", which creates a cast which must be explicitely invoked.
>>
>> I'm not sure this is a good idea. The CREATE CAST syntax is in the SQL
>> st
Wow, this is the first I am hearing GNU cp -i can return zero exit if it
doesn't do the copy. I tested this on Ubuntu 10.04 using cp 7.4 and
got:
$ touch x y
$ cp -i x y; echo $?
cp: overwrite `y'? n
0
I see the same on my anchent BSD/OS machine too:
$ t
On 16 June 2011 00:22, Pavel Stehule wrote:
> I try to apply your patch, but it is finished with some failed hinks.
>
> Please, can you refresh your patch
Hi Pavel,
Thanks for taking a look. I have attached v2 of the patch, as against
current HEAD. I've also added the new patch to the CF app.
On Jun 16, 2011, at 9:31 AM, Greg Smith wrote:
> -A case could be made for making some of these state fields null, instead
> true or false, in situations where the session is not visible. If you don't
> have rights to see the connection activity, setting idle, idle_transaction,
> and active all
Tom Lane wrote:
> Peter Eisentraut writes:
> > On ons, 2011-06-15 at 17:50 -0400, Tom Lane wrote:
> >> Bruce Momjian writes:
> >>> Peter Eisentraut wrote:
> On non-Windows servers you could get this even safer by disabling the
> TCP/IP socket altogether, and placing the Unix-domain sock
Robert Haas writes:
> On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
>> 4. Backend #2 visits the new, about-to-be-committed version of
>> pgbench_accounts' pg_class row just before backend #3 commits.
>> It sees the row as not good and keeps scanning. By the time it
>> reaches the previous ver
On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
> 4. Backend #2 visits the new, about-to-be-committed version of
> pgbench_accounts' pg_class row just before backend #3 commits.
> It sees the row as not good and keeps scanning. By the time it
> reaches the previous version of the row, however, b
ION json;
ERROR: incompatible library "/usr/lib/postgresql/json.so": version mismatch
DETAIL: Server is version 9.1, library is version 9.2.
Similar problems occur with a couple other modules I tried (hstore, intarray).
Joey
json-contrib-no-compat-20110617.patch.gz
Descrip
The attached patch addresses one of the open non-blockers for beta3.
These are tuning points which emerged in testing. The first is more
likely to be helpful. The second may be very important in a few
types of transaction mixes, but I threw in a lot of weasel words and
qualifiers because someon
Robert Haas writes:
> I have been thinking for a while now that it would be sensible to make
> vacuum use a different lock type, much as we do for relation
> extension.
Hmm. I had just been toying with the idea of introducing a new
user-visible locking level to allow separation of anti-vacuum lo
All,
For easy visibility, I've moved all "WIP" patches to their own section
in the current commitfest, at the bottom of the list of pending patches.
Hopefully this way there will be less confusion about what needs to be
committed and what doesn't.
--
Josh Berkus
PostgreSQL Experts Inc.
http://p
On Fri, Jun 17, 2011 at 5:02 PM, Tom Lane wrote:
> As far as I can see, the only simple way to return pg_dump to its
> previous level of safety while retaining this patch is to make it take
> ShareUpdateExclusiveLocks, so that it will still block all forms of
> ALTER TABLE. This is rather unpleas
Excerpts from Tom Lane's message of vie jun 17 17:08:25 -0400 2011:
> Alvaro Herrera writes:
> > Hmm, would there be a problem if a scan on catalog A yields results from
> > supposedly-running transaction X but another scan on catalog B yields
> > result from transaction Y? (X != Y) For example,
Alvaro Herrera writes:
> Hmm, would there be a problem if a scan on catalog A yields results from
> supposedly-running transaction X but another scan on catalog B yields
> result from transaction Y? (X != Y) For example, a scan on pg_class
> says that there are N triggers but scanning pg_trigger
Robert Haas writes:
> I like this feature a lot, but it's hard to imagine that any of the
> fixes anyone has so far suggested can be implemented without
> collateral damage. Nor is there any certainty that this is the last
> bug.
And in fact, here's something else to worry about: consider pg_dum
Excerpts from Tom Lane's message of vie jun 17 13:22:40 -0400 2011:
> With this approach, we would have no serialization anomalies from single
> transactions committing while a scan is in progress. There could be
> anomalies resulting from considering an earlier XID to be in-progress
> while a la
Peter Eisentraut writes:
> On ons, 2011-06-15 at 17:50 -0400, Tom Lane wrote:
>> Bruce Momjian writes:
>>> Peter Eisentraut wrote:
On non-Windows servers you could get this even safer by disabling the
TCP/IP socket altogether, and placing the Unix-domain socket in a
private tempora
Peter Eisentraut writes:
> Is this a bug fix that should be backpatched?
I pinged Joe Conway about this. He is jetlagged from a trip to the Far
East but promised to take care of it soon. I think we can wait for his
review.
regards, tom lane
--
Sent via pgsql-hackers m
On ons, 2011-06-15 at 17:50 -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Peter Eisentraut wrote:
> >> On non-Windows servers you could get this even safer by disabling the
> >> TCP/IP socket altogether, and placing the Unix-domain socket in a
> >> private temporary directory. The "port" wou
On Fri, Jun 17, 2011 at 3:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> Department of second thoughts: I think I see a problem.
>
> Um, yeah, so that doesn't really work any better than my idea.
>
> On further reflection, there's a problem at a higher level than this
> anyway. Even if we can g
Robert Haas writes:
> Department of second thoughts: I think I see a problem.
Um, yeah, so that doesn't really work any better than my idea.
On further reflection, there's a problem at a higher level than this
anyway. Even if we can get a single SnapshotNow scan to produce
guaranteed-self-consi
On Fri, Jun 17, 2011 at 8:15 PM, Robert Haas wrote:
> On Fri, Jun 17, 2011 at 3:08 PM, Simon Riggs wrote:
>> Not so. The extra locking would only occur on the first lock
>> acquisition after DDL operations occur. If that was common then your
>> other performance patch would not be an effective op
On ons, 2011-06-15 at 11:41 +0900, Fujii Masao wrote:
> ISTM that the root problem is that dblink_send_query calls DBLINK_GET_CONN
> though it doesn't accept the connection string as an argument. Since the first
> argument in dblink_send_query must be the connection name, dblink_send_query
> should
On Fri, Jun 17, 2011 at 3:08 PM, Simon Riggs wrote:
> Not so. The extra locking would only occur on the first lock
> acquisition after DDL operations occur. If that was common then your
> other performance patch would not be an effective optimisation. There
> is no additional locking from what I'v
On Fri, Jun 17, 2011 at 2:44 PM, Tom Lane wrote:
> Hmm, yeah, I think this idea is probably better than mine, just because
> of the less dubious semantics. I don't see how you'd make it work for
> generic MVCC scans, because the behavior will be "the database state as
> of some hard-to-predict ti
On Fri, Jun 17, 2011 at 7:24 PM, Robert Haas wrote:
> On Fri, Jun 17, 2011 at 1:22 PM, Tom Lane wrote:
>> Yeah, this seems like a possibly workable direction to explore. I like
>> this better than what Simon is proposing, because it would fix the
>> generic issue for all types of catalog Snapsh
On 16 June 2011 16:30, Heikki Linnakangas
wrote:
> This patch breaks silent_mode=on. In silent_mode, postmaster forks early on,
> to detach from the controlling tty. It uses fork_process() for that, which
> with patch closes the write end of the postmaster-alive pipe, but that's
> wrong because th
On Fri, Jun 17, 2011 at 09:57:13AM -0500, Jaime Casanova wrote:
> On Fri, Jun 10, 2011 at 11:30 AM, David Fetter wrote:
> >
> > This also allows subsequent PITR to other times on the original
> > timeline.
> >
> > Josh B pointed out that since this option to true conflicts with
> > another option,
Robert Haas writes:
> On Fri, Jun 17, 2011 at 2:15 PM, Tom Lane wrote:
>> BTW, there was some mention of changing the timestamp versions of
>> generate_series as well, but right offhand I'm not convinced that
>> those need any change. I think you'll get overflow detection there
>> automatically
Robert Haas writes:
> On Fri, Jun 17, 2011 at 1:22 PM, Tom Lane wrote:
>> Yeah. After mulling it for awhile, what about this idea: we could
>> redefine SnapshotNow as a snapshot type that includes a list of
>> transactions-in-progress, somewhat like an MVCC snapshot, but we don't
>> fill that li
On Fri, Jun 17, 2011 at 2:15 PM, Tom Lane wrote:
> Robert Haas writes:
>> So, I finally got around to look at this, and I think there is a
>> simpler solution. When an overflow occurs while calculating the next
>> value, that just means that the value we're about to return is the
>> last one tha
2010/7/12 Kevin Grittner :
> Pavel Baroš wrote:
>> Dne 9.7.2010 21:33, Robert Haas napsal(a):
>
>>> Please add your patch here, so that it will be reviewed during
>>> the about-to-begin CommitFest.
>>>
>>> https://commitfest.postgresql.org/action/commitfest_view/open
>>>
>>
>> OK, but will you help
On Fri, Jun 17, 2011 at 1:22 PM, Tom Lane wrote:
> Yeah, this seems like a possibly workable direction to explore. I like
> this better than what Simon is proposing, because it would fix the
> generic issue for all types of catalog SnapshotNow scans.
It would also avoid adding more lock manager
Robert Haas writes:
> So, I finally got around to look at this, and I think there is a
> simpler solution. When an overflow occurs while calculating the next
> value, that just means that the value we're about to return is the
> last one that should be generated. So we just need to frob the
> co
On Fri, Jun 17, 2011 at 1:01 PM, Garick Hamlin wrote:
> I wanted to see how much faster unlogged tables might be for an
> app I have, so as a quick test I did:
>
> s/CREATE TABLE/CREATE UNLOGGED TABLE/ to get some numbers.
> Which lead to a crash.
>
> Here is a trimmed down test case:
> $ cat > un
Robert Haas writes:
> On Thu, Jun 16, 2011 at 6:54 PM, Tom Lane wrote:
>> I believe that this is fundamentally unavoidable so long as we use
>> SnapshotNow to read catalogs --- which is something we've talked about
>> changing, but it will require a pretty major R&D effort to make it
>> happen.
On Thu, Jun 16, 2011 at 11:17 PM, Noah Misch wrote:
> I took a look at this patch.
No kidding! Thanks for the very detailed review.
> +1 for Buffer over Buffer * when the value isn't mutated for the caller.
I changed this.
> I suggest revisiting the suggestion in
> http://archives.postgresql.
I wanted to see how much faster unlogged tables might be for an
app I have, so as a quick test I did:
s/CREATE TABLE/CREATE UNLOGGED TABLE/ to get some numbers.
Which lead to a crash.
Here is a trimmed down test case:
$ cat > unlog-test.sql
CREATE UNLOGGED TABLE leases (
mac macaddr NOT NULL,
2011/6/17, Andrew Dunstan :
> On 06/17/2011 11:29 AM, Nicolas Barbier wrote:
>
>> CDATA sections are just syntactic sugar (a form of escaping):
>
> Yeah. OTOH doesn't an empty CDATA section force a child element, where a
> pure empty element does not?
Wow, some Googling around shows that there is
On Jun17, 2011, at 17:46 , Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of vie jun 17 10:49:46 -0400 2011:
> Maybe, but the mnemonic rule seems quite a bit easier (to me anyway).
> In my head I think of ~ as "matches", so "text matches regex", whereas
> "regex matches text" doesn't
On Jun17, 2011, at 18:00 , Robert Haas wrote:
> On Fri, Jun 17, 2011 at 11:46 AM, Alvaro Herrera
> wrote:
>> I guess this wouldn't be much of a problem if you could use ANY/ALL with
>> a function instead of an operator, c.f. map().
>
> Yeah. Or really what you want is a lambda-expression, rather
On Fri, Jun 17, 2011 at 05:21:10PM +0200, Florian Pflug wrote:
> On Jun17, 2011, at 17:15 , Ross J. Reedstrom wrote:
> > On Fri, Jun 17, 2011 at 10:20:04AM -0400, Alvaro Herrera wrote:
> >> Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011:
> >>
> >>> How is that worse than t
On Fri, Jun 17, 2011 at 11:46 AM, Alvaro Herrera
wrote:
> I guess this wouldn't be much of a problem if you could use ANY/ALL with
> a function instead of an operator, c.f. map().
Yeah. Or really what you want is a lambda-expression, rather than a
predefined function.
fold(bool_and, map { val ~
On 06/17/2011 11:29 AM, Nicolas Barbier wrote:
2011/6/17, Andrew Dunstan:
On 06/17/2011 10:55 AM, Radosław Smogura wrote:
XML canonization preservs whitespaces, if I remember
well, I think there is example.
In any case if I will store image in XML (I've seen this), preservation of
white sp
Andrew Dunstan Friday 17 of June 2011 17:09:25
> On 06/17/2011 10:55 AM, Radosław Smogura wrote:
> > Andrew Dunstan Friday 17 of June 2011 15:47:04
> >
> >> On 06/17/2011 05:41 AM, Florian Pflug wrote:
> >>> On Jun17, 2011, at 11:09 , Radosław Smogura wrote:
> 1.
> SELECT (XPATH('/root
Excerpts from Florian Pflug's message of vie jun 17 10:49:46 -0400 2011:
> On Jun17, 2011, at 16:20 , Alvaro Herrera wrote:
> > Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011:
> >> So? How does that reduce that risk of somebody writing "pattern ~ text"
> >> instead of "text
2011/6/17, Andrew Dunstan :
> On 06/17/2011 10:55 AM, Radosław Smogura wrote:
>
>> XML canonization preservs whitespaces, if I remember
>> well, I think there is example.
>>
>> In any case if I will store image in XML (I've seen this), preservation of
>> white spaces and new lines is important.
>
On Jun17, 2011, at 17:15 , Ross J. Reedstrom wrote:
> On Fri, Jun 17, 2011 at 10:20:04AM -0400, Alvaro Herrera wrote:
>> Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011:
>>
>>> How is that worse than the situation with "=~" and "~="?
>>
>> With =~ it is to the right, with
On Jun17, 2011, at 17:09 , Andrew Dunstan wrote:
> If you store images you should encode them anyway, in base64 or hex.
> More generally, data that needs that sort of preservation should possibly be
> in CDATA nodes.
All very true.
Still, ideally we'd return the XML exactly as stored, though, ev
On Fri, Jun 17, 2011 at 10:20:04AM -0400, Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011:
>
> > How is that worse than the situation with "=~" and "~="?
>
> With =~ it is to the right, with ~= it is to the left.
To throw my user opinion into this
Florian Pflug Friday 17 of June 2011 11:41:08
> On Jun17, 2011, at 11:09 , Radosław Smogura wrote:
> > 1.
> > SELECT (XPATH('/root/*', 'http://olacle.com/db";
> > xmlns:p="http://postgresql.org/db";> > db>')); Produces:
> > "{"
> >
> >
> >
> >
> >
> >
> >
> > ",}"
> > In above was r
On 06/17/2011 10:55 AM, Radosław Smogura wrote:
Andrew Dunstan Friday 17 of June 2011 15:47:04
On 06/17/2011 05:41 AM, Florian Pflug wrote:
On Jun17, 2011, at 11:09 , Radosław Smogura wrote:
1.
SELECT (XPATH('/root/*', 'http://olacle.com/db";
xmlns:p="http://postgresql.org/db";>')); Produce
On Fri, Jun 10, 2011 at 11:30 AM, David Fetter wrote:
>
> This also allows subsequent PITR to other times on the original
> timeline.
>
> Josh B pointed out that since this option to true conflicts with
> another option, having both should prevent recovery from even
> starting, and I'll work up a
Andrew Dunstan Friday 17 of June 2011 15:47:04
> On 06/17/2011 05:41 AM, Florian Pflug wrote:
> > On Jun17, 2011, at 11:09 , Radosław Smogura wrote:
> >> 1.
> >> SELECT (XPATH('/root/*', 'http://olacle.com/db";
> >> xmlns:p="http://postgresql.org/db";> >> :db>')); Produces:
> >> "{"
> >>
> >>
On Jun17, 2011, at 16:20 , Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011:
>> So? How does that reduce that risk of somebody writing "pattern ~ text"
>> instead of "text ~ pattern"? Modifying your quote from above
>>
>> foo ~ 'bar'/* foo
On 06/17/2011 10:20 AM, Alvaro Herrera wrote:
alvherre=# \doS ~
Listado de operadores
Esquema | Nombre | Tipo arg izq | Tipo arg der | Tipo resultado |
Descripción
++--+--+--
On Fri, Jun 17, 2011 at 10:39 AM, David Johnston wrote:
> Tangential comment but have you considered emitting a warning (and/or log
> entry) when you are 10,000-50,000 away from issuing the last available
> number in the sequence so that some recognition exists that any code
> depending on the seq
>
> On Wed, Feb 9, 2011 at 4:50 AM, Thom Brown wrote:
> > On 9 February 2011 02:11, Robert Haas wrote:
> >> On Tue, Feb 8, 2011 at 8:30 PM, Andrew Dunstan
> wrote:
> >>> Quite right, but the commitfest manager isn't meant to be a
> >>> substitute for one. Bug fixes aren't subject to the same re
On 17 June 2011 04:44, Robert Haas wrote:
> On Wed, Feb 9, 2011 at 4:50 AM, Thom Brown wrote:
>> On 9 February 2011 02:11, Robert Haas wrote:
>>> On Tue, Feb 8, 2011 at 8:30 PM, Andrew Dunstan wrote:
Quite right, but the commitfest manager isn't meant to be a substitute for
one. Bug f
Excerpts from Florian Pflug's message of vie jun 17 10:03:56 -0400 2011:
> On Jun17, 2011, at 15:36 , Alvaro Herrera wrote:
> > Excerpts from Florian Pflug's message of vie jun 17 04:46:32 -0400 2011:
> >> On Jun17, 2011, at 03:42 , Alvaro Herrera wrote:
> >>> To make matters worse, our delimiters
On Jun17, 2011, at 15:36 , Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of vie jun 17 04:46:32 -0400 2011:
>> On Jun17, 2011, at 03:42 , Alvaro Herrera wrote:
>>> To make matters worse, our delimiters for regexes are the same as for
>>> strings, the single quote. So you get
>>>
>
Andrew Tipton writes:
> At this point I'm a bit lost -- while pg_amop.h has plenty of examples
> of crosstype comparison operators for btree index methods, there are
> none for GiST. Is GiST somehow a special case in this regard?
AFAIR, GIST doesn't use the concept of a crosstype opclass entry.
On 06/17/2011 05:41 AM, Florian Pflug wrote:
On Jun17, 2011, at 11:09 , Radosław Smogura wrote:
1.
SELECT (XPATH('/root/*', 'http://olacle.com/db";
xmlns:p="http://postgresql.org/db";>'));
Produces:
"{"
",}"
In above was reduced to this is different infoset then input, and
those
Excerpts from Florian Pflug's message of vie jun 17 04:46:32 -0400 2011:
> On Jun17, 2011, at 03:42 , Alvaro Herrera wrote:
> > To make matters worse, our delimiters for regexes are the same as for
> > strings, the single quote. So you get
> >
> > foo =~ 'bar'/* foo is the text column, bar is
Bruce Momjian wrote:
> Robert Haas wrote:
> > On Thu, Jun 16, 2011 at 11:47 PM, Bruce Momjian wrote:
> > > Robert Haas wrote:
> > >> > We can pick different options for 9.0, 9.1, and 9.2. ?(For PG 9.0
> > >> > probably only #1 is appropriate.)
> > >>
> > >> I don't like any of these options as wel
On Fri, Jun 17, 2011 at 07:19:39PM +0900, Shigeru Hanada wrote:
> (2011/06/17 8:44), David Fetter wrote:
> > Sorry not to respond sooner.
> >
> > First, the per-column generic options are a great thing for us to
> > have. :)
>
> Thanks for the comments. :-)
>
> > I have an idea I've been using f
On Fri, Jun 10, 2011 at 22:16, Hitoshi Harada wrote:
>
> I reviewed the patch and worried about hard-wired magic number as
> StrategyNumber. At least you should use #define to indicate the
> number's meaning.
>
> In addition, the modified gist_box_consistent() is too dangerous;
> q_box is declared
On 15 June 2011 12:16, Dave Page wrote:
> On Wed, Jun 15, 2011 at 10:53 AM, Ahmed Shinwari
> wrote:
>> Hi All,
>>
>> I faced a bug on Windows while connecting via SSPI authentication. I was
>> able to find the bug and have attached the patch. Details listed below;
>>
>> Postgres Installer: Versio
(2011/06/17 8:44), David Fetter wrote:
> Sorry not to respond sooner.
>
> First, the per-column generic options are a great thing for us to
> have. :)
Thanks for the comments. :-)
> I have an idea I've been using for the next release of DBI-Link that
> has varying levels of data type mapping. I
On Jun17, 2011, at 11:09 , Radosław Smogura wrote:
> 1.
> SELECT (XPATH('/root/*', 'http://olacle.com/db";
> xmlns:p="http://postgresql.org/db";>'));
> Produces:
> "{"
>
>
>
> ",}"
> In above was reduced to this is different infoset then input,
> and those notations are differently inte
Hello,
During review of
https://commitfest.postgresql.org/action/patch_view?id=580 I found
following problems with XPath.
1.
SELECT (XPATH('/root/*', 'http://olacle.com/db";
xmlns:p="http://postgresql.org/db";>'));
Produces:
"{"
",}"
In above was reduced to this is different in
2011/6/17 Mark Kirkwood :
> On 17/06/11 13:08, Mark Kirkwood wrote:
>>
>> On 17/06/11 09:49, Cédric Villemain wrote:
>>>
>>> I have issues applying it.
>>> Please can you remove trailing space?
>>> Also, you can generate a cool patch like this :
>>>
>>> get git-external-diff from postgres/src/tools
On 16.06.2011 23:56, Tom Lane wrote:
Heikki Linnakangas writes:
The complicated part is to ensure that levelsup is always set correctly.
At parse time, levelsup is always set to 0, as the syntax doesn't allow
referencing upper levels directly. When an SQL function is inlined, any
ExpressionPara
On Fri, Jun 17, 2011 at 9:32 AM, simon wrote:
> On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane wrote:
>
>> 2. In response, some other backend starts to reload its relcache entry
>> for pgbench_accounts when it begins its next command. It does an
>> indexscan with SnapshotNow on pg_class to find the
On Jun17, 2011, at 03:42 , Alvaro Herrera wrote:
> To make matters worse, our delimiters for regexes are the same as for
> strings, the single quote. So you get
>
> foo =~ 'bar' /* foo is the text column, bar is the regex */
> 'bar' =~ foo /* no complaint but it's wrong */
>
> 'bar' ~= foo /*
On Thu, Jun 16, 2011 at 11:54 PM, Tom Lane wrote:
> 2. In response, some other backend starts to reload its relcache entry
> for pgbench_accounts when it begins its next command. It does an
> indexscan with SnapshotNow on pg_class to find the updated pg_class row.
>
> 3. Meanwhile, some third ba
(2011/06/12 6:43), Noah Misch wrote:
> On Wed, Mar 30, 2011 at 04:48:26PM -0400, Robert Haas wrote:
>> Me neither. If making the deadlock timeout PGC_SUSET is independently
>> useful, I don't object to doing that first, and then we can wait and
>> see if anyone feels motivated to do more.
>
> Her
evised patch attached.
Regards,
--
Hitoshi Harada
aggjoin-20110617.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
86 matches
Mail list logo
