t, to give better error handling.
This looks good to go to me. Reviewing this as "Ready for Committer".
Thanks for the patch, Pierre!
Ryan
The new status of this patch is: Ready for Committer
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
ul 2017, at 08:32, Michael Paquier
> > > wrote:>
> > > On Wed, Jul 5, 2017 at 2:57 PM, Ryan Murphy
> wrote:
> > >> I tried to apply your patch to test it (though reading Robert's last
> > >> comment it seems we wish to have it adjusted before commi
't caused by your patch.
Thanks,
Ryan
e: FATAL: database
"regress_ecpg_user2" does not exist
...
But this still Needs Review by someone who knows the JOIN system better.
Best,
Ryan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> FWIW, I find that good ol' patch is much more reliable about applying
> patches that didn't come from git itself. In this case
>
>
Thanks, I knew I was missing something!
Ryan
om source.
In both cases I got the same error.
I know you recently rebased this patch already, but could you please
double-check it?
Of course it's possible I'm doing something wrong.
Thanks,
Ryan
The new status of this patch is: Waiting on Author
--
Sent via pgsql-hackers mailin
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
I've reviewed the code changes, and it's pretty clear to me t
> Thanks for reporting it!
>
My pleasure!
So the initial issue didn't happen the 2nd time. So if misc_sanity was the
only test
failing then I guess my tests are working fine other than that. Sweet!
When I get a break from work I'll review some patches!
Best,
Ryan
anity ... ok
test misc_sanity ... FAILED
test comments ... ok
test expressions ... ok
test insert ... ok
test insert_conflict ... ok
test create_function_1 ... ok
...
The old failure with the missing error message is gone from
connect: could not open database: FATAL: database
"regress_ecpg_user2" does not exist
Why would this database not be getting created? The full diffs file is
attached.
Thanks for your help!
Ryan
regression.diffs
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hacker
Poking this. Looking back through the discussion, this issue has been
reproduced by multiple people. The patch still applies to HEAD without issues.
I have no experience with PostgreSQL replication, so I'm not qualified to
really review this. From what I can see with the patch, it's just a s
Hi Michael,
I tried to apply your patch to HEAD and it failed. But I think that's because
some version of it has already been committed, correct? I see some of your
ECONNRESET and "SSL connection has been closed unexpectedly" code already in
HEAD.
Best,
Ryan
The new status o
nger apply, so I can rebase and repost ASAP.)
>
>
Smart idea! I may try this in the future.
Best,
Ryan
On Author for a new patch, and I also
agree with Robert that the test can be simpler and can go in the other order.
If you don't have time to make another patch, let me know, I may be able to
make one.
Thanks!
Ryan
The new status of this patch is: Waiting on Author
--
Sent via pgsql-hacke
there a place within the
CommitFest where it says what version to have checked out?
Thank you,
Ryan
The following review has been posted through the commitfest application:
make installcheck-world: not tested
Implements feature: not tested
Spec compliant: not tested
Documentation:not tested
This commit only affects comments, so I'm confident it doesn't break code,
t
> > You'll probably want to do those at a C level, bypassing the executor. I
> > would guess that executor overhead will completely swamp the effect of
> the
> > cache in most cases.
>
> That seems like it's kind of missing the point. If the tupleDesc
> cache saves so little that it's irrelevant w
> attcacheoff can only be set positive for fields preceding any varlena
> (typlen<0, but including the first such) or nullable values. I don't
> know how much faster it is with the cache; you can measure it if your
> curiosity is strong enough -- just set the first column to nullable.
>
>
Thanks!
> No, that tests whether the particular tuple contains any null fields, not
> whether the whole table is declared NOT NULL.
>
> regards, tom lane
>
Ok, thanks, that makes sense.
My question kind of remains though - does that mean that having any nulls
in the tuple loses th
irst to see if there are
any columns that can be NULL. It looks like the fetchatt() that uses the
cache in the tupleDesc can only be used if there are no NULLable columns in
the table. Is my understanding correct? Does this mean that there is
significant performance gain by never allowing any column to be null in
your table?
Thanks!
Ryan
>
> There are no in-core operators or functions to manipulate pg_node_tree.
>
Thanks Michael, just checking!
access the members of a json
or jsonp value (using -> or ->>). Is there anything analogous for
pg_node_tree?
Thanks!
Ryan
> The on-screen output isn't all that helpful for diagnosing what went
> wrong. You might learn more by looking at the regression.diffs files.
> Remember that errors tend to cascade, so the first one(s) in any
> particular test suite are the most important --- the rest might just
> be fallout.
>
>
>
> Jim Nasby said I shouldn't necessarily need to build the docs / the whole
> world in order to review patches. But the Review form needs a `make
> installworld-check`. Do I need to install the whole world in order to meet
> this requirement? Happy to do so if required, but in that case, I won
>
>
> Ryan try to run 'make install-world' then 'make -i installcheck-world', -i
> option will ignore the error and proceed. You can check if any other tests
> fails. This is a separate issue, unrelated to this patch. I do not think
> we should stop fr
w if I have
any questions.
Take care,
Ryan
> AFAICS, what Ryan is after would be better served by a separate tool that
> would produce a "diff" of the two tables' schemas.
Related to the other idea of seeing the problems that exist in all the
> columns (instead of one column at a time), I think it'd be reasona
> Perhaps the ERROR message should remain as is, and a DETAIL or HINT line
> could be emitted with the entire column definition (or close to it)?
>
>
I'm open to this option as well. The only parts I really care about are
the type and the NOT NULL, since those are the ones that will give you an
er
> No, and TBH I would vote strongly against including that much detail in
> this error message anyway. That info could be indefinitely long, and it's
> not especially relevant to the stated error condition --- for example, the
> presence of a default is *not* relevant to whether the column matches
ludes all those additional
constraints/defaults etc? I noticed that defaults seem to be stored in the
Form_pg_attrdef struct defined in src/include/catalog/pg_attrdef.h, and
haven't yet seen how constraints like NOT NULL are handled.
Thanks,
Ryan
> The approved way to do this is with format_type_be(), or
> format_type_with_typemod() if you want to include typmod info, which
> I think you probably do for the intended use-case.
>
> regards, tom lane
>
Thanks Tom, I'll redo the patch using one of those, and get back to
t-type-name
logic from getTypeOutputInfo() so probably needs a factor), and I'd
ultimately love for it to list NOT NULL, DEFAULTs and other constraints to
make it easier to prepare a table to inherit from another.
Thoughts / suggestions? Does this seem useful to you guys?
Best,
Ryan
000
The following review has been posted through the commitfest application:
make installcheck-world: tested, failed
Implements feature: tested, passed
Spec compliant: tested, passed
Documentation:tested, passed
(Though I could not check "make installcheck-world" as passed
> Making --wait the default may or may not be sensible -- I'm not sure
> -- but removing --no-wait is clearly a bad idea, and we shouldn't do
> it. The fact that the problems created by removing it might be
> solvable doesn't mean that it's a good idea to create them in the
> first place.
>
>
>
I
27;s such a
simple change that if one of the core devs wants this s/he can probably
more easily just add it themselves.
Cheers,
Ryan
>
> On Mac, the recommended thing is to forget about the ossp code and
>> use "configure --with-uuid=e2fs". Sorry if that wasn't clear enough.
>>
>>
> Ok thanks, I'll try this.
>
Thanks Tom, "uuid-ossp" built perfectly with "--with--uuid=e2fs".
Cheers and Happy Holidays!
Ryan
oing into e.g.
contrib/pgcrypto and typing make to build the pgcrypto extension. Since
things like that have generally worked for me I didn't learn about the
proper flags etc.
I'll try some more things and get back to you, thanks for the help.
Best,
Ryan
nt
backends. I was looking for documentation about how to choose a backend /
more details on how to build this extension now, but drawing a blank.
Again I am on a Mac, this is my compiler info:
$ clang -v
Apple LLVM version 7.0.2 (clang-700.1.79)
Target: x86_64-apple-darwin14.0.0
Thread model: posix
Thanks much!
Ryan
>
> please, can you check attached patch? It worked in my laptop.
>
> Regards
>
> Pavel
>
>
Yes, that one applied for me without any problems.
Thanks,
Ryan
n the meantime, I haven't had a chance to try out the fileref feature yet but
I'll give it a go when I get a chance!
Thanks!
Ryan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Thanks for committing it Tom! Thank you all for your help.
I really like the Postgres project! If there's anything that especially
needs worked on let me know, I'd love to help.
Best,
Ryan
>
> I looked into this and soon found that fe_utils/string_utils.o has
> dependencies on libpq that are much wider than just pqexpbuffer :-(.
> It might be a project to think about sorting that out sometime, but it
> looks like it would be an awful lot of work just to avoid having initdb
> depend o
On Sat, Aug 20, 2016 at 8:26 AM, Michael Paquier
wrote:
> On Sat, Aug 20, 2016 at 4:39 AM, Ryan Murphy
> wrote:
> > Here is another version of my initdb shell quoting patch. I have removed
> > the unnecessary {} block. I also ran pgindent on the code prior to
> c
Here is another version of my initdb shell quoting patch. I have removed
the unnecessary {} block. I also ran pgindent on the code prior to
creating the patch.
On Thu, Aug 18, 2016 at 3:50 PM, Ryan Murphy wrote:
>
>
> On Thu, Aug 18, 2016 at 3:44 PM, Tom Lane wrote:
>
>> R
On Thu, Aug 18, 2016 at 3:44 PM, Tom Lane wrote:
> Ryan Murphy writes:
> > On Thu, Aug 18, 2016 at 3:22 PM, Robert Haas
> wrote:
> >>>> +{ /* pg_ctl command w path, properly quoted */
> >>>> +P
On Thu, Aug 18, 2016 at 3:22 PM, Robert Haas wrote:
> On Thu, Aug 18, 2016 at 4:15 PM, Andres Freund wrote:
> > On 2016-08-18 16:11:27 -0400, Robert Haas wrote:
> >> On Wed, Aug 17, 2016 at 11:18 PM, Andres Freund
> wrote:
> >> > On August 17, 2016 8:15:56 PM PDT, Michael Paquier <
> michael.pa
newline in a file name.
Did you see anything else in my code that you have recommendations about?
I made sure to free the PQExpBufferStr vars that I allocated.
Best,
Ryan
On Wed, Aug 17, 2016 at 7:41 PM, Andres Freund wrote:
> On 2016-08-18 09:14:44 +0900, Michael Paquier wrote:
> > O
That's a fair point Michael. I would be willing to make such a change, but
since c doesn't have optional function arguments I'm not sure the least
intrusive way to do that. Do you have a suggestion?
On Wednesday, August 17, 2016, Michael Paquier
wrote:
> On Thu, Aug 18, 2016
I have created a better patch (attached) that correctly escapes the shell
arguments using PQExpBufferStr and the appendShellString function, as per
Michael and Andres' suggestions.
Further suggestions welcome of course.
Ryan
On Wed, Aug 17, 2016 at 8:28 AM, Ryan Murphy wrote:
> Th
That makes sense, Michael and Andres.
I started to make a solution that uses a PQExpBuffer, appendShellString,
etc. I think it will work just fine, but I think I need to alter the
Makefile as well, to get initdb.c to be compiled using
-L../../../src/fe_utils -lpgfeutils. Otherwise I am having is
I've submitted my patch to Commitfest 2016-09.
https://commitfest.postgresql.org/10/718/
My username on postgresql.org is murftown
On Tue, Aug 16, 2016 at 1:02 AM, Ryan Murphy wrote:
> Ok, I'll do that!
> Thanks Michael!
> Ryan
>
>
> On Monday, August 15, 20
Ok, I'll do that!
Thanks Michael!
Ryan
On Monday, August 15, 2016, Michael Paquier
wrote:
> On Mon, Aug 15, 2016 at 12:12 AM, Ryan Murphy > wrote:
> > This is to fix an issue that came up for me when running initdb.
> >
> > At the end of a successful initdb it s
for non-windows cases.
Therefore, added quotes via existing QUOTE_PATH constant:
pg_ctl -D '/some/path/to/data' -l logfile start
Best,
Ryan
0001-initdb-for-QUOTE_PATH-non-windows.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.or
Hello Postgres Team!
This is to fix an issue that came up for me when running initdb.
At the end of a successful initdb it says:
Success. You can now start the database server using:
pg_ctl -D /some/path/to/data -l logfile start
but this command did not work for me because my data d
On Thu, Aug 11, 2016 at 10:42 AM, Ryan Pedela
wrote:
> On Thu, Aug 11, 2016 at 9:27 AM, Oleg Bartunov
> wrote:
>
>> On Tue, Aug 9, 2016 at 9:59 PM, Ryan Pedela
>> wrote:
>> >
>> >
>>
>> > I would say that it is worth it to have a &qu
On Thu, Aug 11, 2016 at 9:27 AM, Oleg Bartunov wrote:
> On Tue, Aug 9, 2016 at 9:59 PM, Ryan Pedela
> wrote:
> >
> >
>
> > I would say that it is worth it to have a "phrase slop" operator (Apache
> > Lucene terminology). Proximity search is extre
On Tue, Aug 9, 2016 at 12:59 PM, Ryan Pedela wrote:
>
>
> Thanks,
>
> Ryan Pedela
> Datalanche CEO, founder
> www.datalanche.com
>
> On Tue, Aug 9, 2016 at 11:58 AM, Tom Lane wrote:
>
>> Bruce Momjian writes:
>> > Does anyone know why the ph
Thanks,
Ryan Pedela
Datalanche CEO, founder
www.datalanche.com
On Tue, Aug 9, 2016 at 11:58 AM, Tom Lane wrote:
> Bruce Momjian writes:
> > Does anyone know why the phrase distance "<3>" was changed from "at most
> > three tokens away" to "ex
On Mon, May 23, 2016 at 11:14 AM, David G. Johnston <
david.g.johns...@gmail.com> wrote:
> On Mon, May 23, 2016 at 12:55 PM, Peter van Hardenberg wrote:
>
>> Hi there,
>>
>> I noticed it was very easy to accidentally call the json_* form of JSON
>> manipulation functions with jsonb data as input.
Tika [1] for plain text extraction from HTML.
There are so many weird edge cases when parsing HTML that it is easier to
use something that is already mature than reinventing the wheel.
1. https://tika.apache.org/
Thanks,
Ryan Pedela
On Tue, Apr 26, 2016 at 10:49 AM, Stephen Frost wrote:
> * Ryan Pedela (rped...@datalanche.com) wrote:
> > On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni
> wrote:
> > > The default text representation of jsonb adds whitespace in between
> > > key/value pairs (
On Sun, Apr 24, 2016 at 4:02 PM, Sehrope Sarkuni wrote:
> Hi,
>
> The default text representation of jsonb adds whitespace in between
> key/value pairs (after the colon ":") and after successive properties
> (after the comma ","):
>
> postgres=# SELECT '{"b":2,"a":1}'::jsonb::text;
>text
On Mon, Sep 28, 2015 at 4:09 PM, Jim Nasby wrote:
> On 9/28/15 11:43 AM, Andres Freund wrote:
>
>> On 2015-09-28 09:41:18 -0700, David Fetter wrote:
>>
>>> Since you're convinced that this is an unqualified win, please put
>>> together a project plan for switching from our current system to
>>> G
list when an issue is created or
updated.
2. Replies to the email will automatically update the issue on Github.
3. Github is where most of the OSS activity happens now.
4. If Github goes away, so what? The core workflow never changes.
Thanks,
Ryan Pedela
vascript users?
References
1. https://github.com/datalanche/json-bignum
2. https://github.com/iriscouch/bigdecimal.js
Thanks,
Ryan
On Wed, Jul 15, 2015 at 11:10 AM, Ryan Pedela
wrote:
> On Wed, Jul 15, 2015 at 8:52 AM, Robert Haas
> wrote:
>
>> FWIW, I don't agree. If it's not easy to read the JSON that
>> PostgreSQL generates using JavaScript, then a lot of people are just
>> going
On Wed, Jul 15, 2015 at 8:52 AM, Robert Haas wrote:
> FWIW, I don't agree. If it's not easy to read the JSON that
> PostgreSQL generates using JavaScript, then a lot of people are just
> going to give up on doing it, and IMO that would be sad. Telling
> people that they have to parse the JSON u
wise to add something to core just because one client
does stupid things with large numbers. In addition, ES7 is introducing
"value types" which will hopefully solve the large number problem in
Javascript.
The random whitespace issue is valid in my opinion and should be fixed.
Thanks,
Ryan Pedela
On Fri, May 22, 2015 at 10:51 AM, Merlin Moncure wrote:
> On Fri, May 22, 2015 at 9:43 AM, Alvaro Herrera
> wrote:
> > Andrew Dunstan wrote:
> >>
> >> On 05/20/2015 09:16 AM, Shulgin, Oleksandr wrote:
> >
> >> >Attached is a patch against master to generalize the JSON-producing
> >> >functions i
On Wed, May 20, 2015 at 12:34 PM, Andrew Dunstan
wrote:
>
> So Dmitry, at my suggestion, has come up with a way of doing that, by
> adding a parameter to jsonb_replace(). If this parameter is set to true (it
> defaults to false) and the key or array element pointed to by the last
> element of the
On Mon, May 18, 2015 at 12:24 PM, Josh Berkus wrote:
>
> On 05/18/2015 08:57 AM, Ryan Pedela wrote:
> > If not, deep concatenation would solve this problem, but I can also see
> > another solution. Use + for shallow concatenation since it really means
> > "add elemen
On Mon, May 18, 2015 at 8:41 AM, Ryan Pedela wrote:
> On Sun, May 17, 2015 at 9:41 PM, Josh Berkus wrote:
>
> Is there a particular reason why "+" makes more sense as "shallow
>> concatination" and "||" makes more sense as "deep concati
abase use case is being able to delete or replace/update a
specific, nested path in the JSON object. It looks like that is possible
with the minus operator and jsonb_replace(). This is great, however it took
me awhile to figure out the path syntax. I think adding a paragraph to the
docs explaining the path syntax would help.
Ryan Pedela
On Wed, Mar 25, 2015 at 11:59 AM, Alvaro Herrera
wrote:
>
>
> * Should we prohibit DDL from within event triggers?
>
Please don't prohibit DDL unless there is a really, really good reason to
do so. I have several use cases in mind for event triggers, but they are
only useful if I can perform DDL.
ort in event triggers is the
upcoming feature I am most excited about, and I am happy to see progress.
Thanks,
Ryan Pedela
On Tue, Feb 3, 2015 at 11:10 AM, Tom Lane wrote:
> Ryan Kelly writes:
>> The attached patch adds a LINE: ... hint when schemaname.typename
>> results in a schema which does not exist. I came across this when a
>> missing comma in a SELECT list resulted in an error witho
st" does not exist
LINE 1: select test.id 'all' as example from test;
^
LOCATION: LookupTypeName, parse_type.c:171
-Ryan Kelly
missing_type_schema_hint.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
On 16/10/2014 7:59 AM, Robert Haas wrote:
On Thu, Oct 16, 2014 at 9:30 AM, Andres Freund wrote:
On 2014-10-16 09:19:16 -0400, Robert Haas wrote:
On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson
wrote:
Why not use an RCU mechanism [1] and ditch the hazard pointers? Seems like
an ideal fit
On 16/10/2014 7:19 AM, Robert Haas wrote:
On Thu, Oct 16, 2014 at 8:03 AM, Ryan Johnson
wrote:
Why not use an RCU mechanism [1] and ditch the hazard pointers? Seems like
an ideal fit...
In brief, RCU has the following requirements:
Read-heavy access pattern
Writers must be able to make dead
don't forget to quiesce all in-flight
back ends at regular intervals, or the system won't be able to reclaim
anything...
Thoughts?
Ryan
n.edu/~mfreed/docs/cuckoo-eurosys14.pdf
Actually, I'd go with second-chance hashing [2], same number of hash
functions but it's more stable (no infinite loops, for example). Most
probably the techniques from [1] would apply equally well.
[2]
http://www.eecs.harvard.edu/~michaelm/p
If PL/Javascript is a serious consideration, how will int64 and numeric be
handled?
Thanks,
Ryan Pedela
Datalanche CEO, co-founder
www.datalanche.com
rped...@datalanche.com
513-571-6837
On Tue, Sep 2, 2014 at 6:38 AM, Andrew Dunstan wrote:
>
> On 09/02/2014 05:44 AM, Álvaro Hernández T
On 27/06/2014 8:20 AM, Alvaro Herrera wrote:
Ryan Johnson wrote:
On 26/06/2014 11:04 PM, Alvaro Herrera wrote:
Ryan Johnson wrote:
As part of a research project, I'm trying to change Read Committed
isolation to use HeapTupleSatisfiesNow rather than acquiring a new
snapshot at every comma
On 27/06/2014 3:14 AM, Andres Freund wrote:
On 2014-06-26 22:47:47 -0600, Ryan Johnson wrote:
Hi,
As part of a research project, I'm trying to change Read Committed isolation
to use HeapTupleSatisfiesNow rather than acquiring a new snapshot at every
command [1]. Things appear to have
On 26/06/2014 11:04 PM, Alvaro Herrera wrote:
Ryan Johnson wrote:
As part of a research project, I'm trying to change Read Committed
isolation to use HeapTupleSatisfiesNow rather than acquiring a new
snapshot at every command [1].
Are you aware of this?
c
scan->xs_continue_hot;
there seems to be code in place to detect when a non-MVCC snapshot is in
use, as if that were nothing out of the ordinary, but nothing prevents
the error from arising if a hot chain is actually encountered.
Thanks,
Ryan
[1] Right now, Read Committed is significantl
such as:
// applies a JSON Patch
json_patch_apply(json, patch)
// diffs two JSON objects and produces a JSON Patch
json_patch_diff(json a, json b)
Thanks,
Ryan Pedela
this you sources.list line:
deb http://apt.postgresql.org/pub/repos/apt/ precise-pgdg main 9.3
This is recommended by:
https://wiki.postgresql.org/wiki/Apt/FAQ#I_want_to_try_the_beta_version_of_the_next_PostgreSQL_release
-Ryan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
...@llserver.lakeliving.com
Never went anywhere though.
-Ryan P. Kelly
On Tue, May 05/14/13, 2013 at 11:35:36AM -0400, Peter Eisentraut wrote:
> Sometimes, the psql startup hangs when it cannot resolve or connect to a
> host. Intuitively, I would like to press Ctrl+C and correct the
> connection
need to first CREATE EXTENSION file_fdw. Then you need to CREATE
SERVER. Then CREATE FOREIGN TABLE. Which requires appropriate permission
to do those things, and certainly has no hope of working on the client
side.
-Ryan P. Kelly
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql
using the FDW machinery to perform many queries to be much slower
than importing the data once and then running my queries. There is also
no ability to use indexes.
> > so weighing it down with processing options seems like a pretty
> > dubious idea even if the implementation were easy
On Mon, Jul 09, 2012 at 05:35:15PM +0900, Shigeru HANADA wrote:
> Hi Ryan,
>
> On Mon, Jun 25, 2012 at 9:00 PM, Ryan Kelly wrote:
> >> Connection attempt by \connect command could be also canceled by
> >> pressing Ctrl+C on psql prompt.
> >>
> >> In a
regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
-Ryan Kelly
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Shigeru:
Thank you very much for your review. Comments are inline below, and a
new patch is attached.
On Fri, Jun 22, 2012 at 10:06:53AM +0900, Shigeru HANADA wrote:
> (2012/05/01 0:30), Ryan Kelly wrote:
> >On Mon, Apr 30, 2012 at 09:02:33AM -0400, Alvaro Herrera wrote:
> >>W
I had trouble finding what operators arrays supported or which ones
had index support or even determining that arrays could be indexed from
the documentation from the array data type. So, patch.
-Ryan Kelly
diff --git a/doc/src/sgml/array.sgml b/doc/src/sgml/array.sgml
index 3508ba3..51d996d
encryption. Ie. only support the 'null' encryption method. That should be
> >>> about the same amount of work as writing an implementation of compression
> >>> using whatever protocol we would decide to use for negotiating the
> >>> compression.
> >
On Mon, Apr 30, 2012 at 09:02:33AM -0400, Alvaro Herrera wrote:
>
> Excerpts from Ryan Kelly's message of lun abr 30 07:10:14 -0400 2012:
> > On Sun, Apr 29, 2012 at 10:12:40PM -0400, Alvaro Herrera wrote:
> > >
> > > Excerpts from Ryan Kelly's m
On Sun, Apr 29, 2012 at 10:12:40PM -0400, Alvaro Herrera wrote:
>
> Excerpts from Ryan Kelly's message of sáb ene 14 16:22:21 -0300 2012:
>
> > I have attached a new patch which handles the connect_timeout option by
> > adding a PQconnectTimeout(conn) function to
On Tue, Jan 10, 2012 at 11:29:58AM +0200, Heikki Linnakangas wrote:
> On 09.01.2012 15:49, Ryan Kelly wrote:
> >On Mon, Jan 09, 2012 at 10:35:50AM +0200, Heikki Linnakangas wrote:
> >>That assumes that it's safe to longjmp out of PQconnectdbParams at
> >>any in
On Mon, Jan 09, 2012 at 10:35:50AM +0200, Heikki Linnakangas wrote:
> On 08.01.2012 22:18, Ryan Kelly wrote:
> >@@ -1570,7 +1570,13 @@ do_connect(char *dbname, char *user, char *host, char
> >*port)
> > keywords[7] = NULL;
> > values[7] = NULL;
1 - 100 of 194 matches
Mail list logo
