them
create another.
What problems do you see with that?
Yeah, I don't know why it need be handled any different than say
ALTER DATABASE foo SET config_param TO value
or
ALTER ROLE foo SET config_param TO value
These cases do not effect already existing processes either.
Joe
--
Joe
. If these
two settings could be restricted by the DBA, there would be a much lower
chance of this happening. There are undoubtedly other holes to fill, but
it seems like a worthy cause.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training
/REVOKE on SET.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org
/9.0/interactive/contrib-dblink-send-query.html
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
in Makefile of
contrib, as follows:
# against installed postmaster
installcheck: submake $(REGRESS_PRE)
$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
Seems reasonable.
+1
it would have been helpful to me last month while looking at this.
Joe
--
Joe Conway
credativ LLC: http
to make time either Tuesday or Wednesday evening this week to do more
review, but since I'm now on a business trip I can't guarantee it.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
--
Sent via pgsql
-SELECT and could find no
reference to COLLATE. Can anyone point me to some documentation that
would explain what that error message means and how to resolve it?
Thanks,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting
On 06/29/2011 04:18 PM, Joe Conway wrote:
1) COLLATE clause is a new feature in 9.1?
2) The doc search feature on postgresql.org does not search the 9.1
documentation?
I looked in the 9.1 docs in SQL Commands-SELECT and could find no
reference to COLLATE. Can anyone point me to some
On 06/29/2011 05:34 PM, Joe Conway wrote:
The third key passed to SearchSysCache is CStringGetTextDatum(provider).
Ultimately FunctionCall2Coll gets called with collation == 0 and
varstr_cmp fails due to the ambiguity.
Is there something new that should be used in place
with dblink_send_query goes back through 8.4, while
dblink_record_internal could be fixed as far back as 8.2.
However, since this is really just a case of unused variables and not a
leaked connection, I'm inclined to just fix git master -- comments on that?
Joe
--
Joe Conway
credativ LLC: http
On 06/17/2011 01:05 PM, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net 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
On 05/05/2011 09:00 PM, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Right -- I think another similar problem exists in GetNewMultiXactId
where ExtendMultiXactOffset could succeed and write an XLOG entry and
then ExtendMultiXactMember could fail before advancing nextMXact
, so a simple
reversal doesn't help.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
signature.asc
Description: OpenPGP digital signature
).
Thanks,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
signature.asc
Description: OpenPGP digital signature
On 03/03/2011 03:49 PM, Jim Nasby wrote:
On Mar 2, 2011, at 2:54 PM, Joe Conway wrote:
On 03/02/2011 12:41 PM, Tom Lane wrote:
Looks like the process trying to do the ALTER has already got some
lower-level lock on the table. It evidently hasn't got
AccessExclusiveLock, but nonetheless has
as a specific fix. Thoughts?
Thanks,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
signature.asc
Description: OpenPGP digital signature
).
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
signature.asc
Description: OpenPGP digital signature
.x86_64.rpm
http://www.joeconway.com/rpms/kernel-2.6.18-238.el5.nfslseekfixv2.src.rpm
HTH,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
signature.asc
Description: OpenPGP digital signature
On 10/08/2010 08:12 PM, Robert Haas wrote:
On Fri, Oct 8, 2010 at 4:31 PM, Joe Conway m...@joeconway.com wrote:
I'm finally trying to get current with the switch to git, following this
wiki page:
http://wiki.postgresql.org/wiki/Committing_with_Git
Specifically, I am trying to do
Thanks,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
mkdir /opt/src/pgsql-git
cd /opt/src/pgsql-git
git clone --bare --mirror ssh://g...@gitmaster.postgresql.org/postgresql.git
cd /opt/src/pgsql-git
On 09/09/2010 09:11 AM, Joe Conway wrote:
The attached patch is updated for the various comments, as well as some
wording tweaks by me. If there are no objections I'd like to commit this
in a day or two.
Committed.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL
for the various comments, as well as some
wording tweaks by me. If there are no objections I'd like to commit this
in a day or two.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
? src/backend/parser/parse.h
it on a checkout from CVS head. Basically do
make
make install
initdb
pg_ctl start
make installcheck
pg_ctl -m immediate stop
pg_ctl start
At this point I see the assertion in the logs.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training
(a, b, c);
cmp_ok
t
t
f
(3 rows)
HTH,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
signature.asc
Description: OpenPGP digital signature
(see separate email about
migration timeline).
Interesting list -- some names on there I haven't seen in a long time...
Mine is fine.
Thanks,
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
on Solaris
Sparc. Any chance you can get a backtrace from a build with debug symbols?
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
signature.asc
Description: OpenPGP digital signature
if possible. I'll keep you posted...
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, 24x7 Support
signature.asc
Description: OpenPGP digital signature
anything on the Serializable Wiki page which is unclear,
please feel free to fix it or let me know. I'm hoping to ultimately
draw from that for a README file.
Sounds good -- exactly what I was thinking as I reviewed it.
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL
, line 18, in module
from dtester.events import EventMatcher, EventSource, Event, \
ImportError: No module named dtester.events
8-
Another python package I'm missing?
Joe
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
On 07/18/2010 07:02 PM, Joe Conway wrote:
On 07/18/2010 11:41 AM, Kevin Grittner wrote:
To run the tests included in the main patch (if you have python,
twisted, etc., installed), after the make check, run make dcheck.
Question about dcheck. After install of twisted, I get:
8
://commitfest.postgresql.org/action/patch_view?id=310
--
Joe Conway
credativ LLC: http://www.credativ.us
Linux, PostgreSQL, and general Open Source
Training, Service, Consulting, Support
signature.asc
Description: OpenPGP digital signature
On 06/30/2010 05:52 PM, Robert Haas wrote:
And at any rate, the per-database thing isn't really the design goal,
anyway.
FWIW, I've run into more than one client where PITR and/or warm standby
on a per-database level would be a killer feature.
Joe
signature.asc
Description: OpenPGP digital
On 06/14/2010 10:58 AM, Tom Lane wrote:
A recent bug report
http://archives.postgresql.org/pgsql-admin/2010-06/msg00101.php
shows that dblink_build_sql_update and friends are really not all there
when it comes to dealing with dropped columns in the target table.
Yup, was just looking at
On 06/14/2010 11:21 AM, Tom Lane wrote:
Actually, I was working on it myself. On further reflection I think
that logical numbers are clearly the right thing --- if we define it
as being physical numbers then we will have headaches in the future
when/if we support rearranging columns.
On 06/14/2010 11:54 AM, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
I didn't even think people were using those functions for many years
since I never heard any complaints. I'd say better to not backpatch
changes to logical ordering, but FWIW the attached at least fixes
On 05/27/2010 12:39 PM, Robert Haas wrote:
On Thu, May 27, 2010 at 3:15 PM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
Jesper Krogh jes...@krogh.cc wrote:
Couldn't pages that are totally filled by the same transaction, be
frozen on the initial write?
As far as I'm aware, that can
On 05/25/2010 08:03 PM, Tom Lane wrote:
Takahiro Itagaki itagaki.takah...@oss.ntt.co.jp writes:
There is an open item pg_controldata - machine readable? in the list:
http://wiki.postgresql.org/wiki/PostgreSQL_9.0_Open_Items
The proposal by Joe Conway is adding a new contib module.
http
On 05/07/2010 09:06 PM, Nikhil Sontakke wrote:
Yeah this is my basic confusion. But wouldn't the arguments be
evaluated afresh on the subsequent call for this SRF?
No, see ExecMakeFunctionResult(). If we did that we'd have serious
problems with volatile functions, ie srf(random()).
Ok
On 05/08/2010 09:12 AM, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
I think this is an example of why we still need to implement a real
SFRM_ValuePerCall mode that allows results to be pipelined. Yes,
ValuePerCall sort of works from the targetlist, but it is pretty much
useless
On 04/09/2010 07:33 AM, Robert Haas wrote:
On Fri, Apr 9, 2010 at 7:55 AM, Yeb Havinga yebhavi...@gmail.com wrote:
'tagging' a datatype as a lineair order, it could automatically have a range
type defined on it, like done for the array types currently.
The way we've handled array types is,
On 03/15/2010 02:42 AM, Magnus Hagander wrote:
I think we need to look at this as a single problem needing to be
solved, and then have the same solution applied to dblink and
walreceiver.
+1
Joe
signature.asc
Description: OpenPGP digital signature
On 03/05/2010 10:28 AM, Greg Smith wrote:
Heikki Linnakangas wrote:
Then again, if you don't use the copy in shared memory but just open the
pg_control file and read it in the UDF, you could implement this as a
pgfoundry module that works with older versions too.
This is the direction I'd
On 03/04/2010 02:09 PM, Joshua Tolley wrote:
On Thu, Mar 04, 2010 at 10:54:15PM +0100, Magnus Hagander wrote:
2010/3/4 Josh Berkus j...@agliodbs.com:
pg_controldata --catalog_version
Even better would be the ability to get everything which is in
pg_controldata currently as part of a system
On 02/03/2010 04:49 AM, Rushabh Lathia wrote:
Testcase:
create table foo (a int );
postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\0\,
\a\}','{\99\, \xyz\}');
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
server closed the connection unexpectedly
Thanks for
On 02/03/2010 04:49 AM, Rushabh Lathia wrote:
create table foo (a int );
postgres=# SELECT dblink_build_sql_insert('foo','1 2',2,'{\0\,
\a\}','{\99\, \xyz\}');
HINT: Use the escape string syntax for escapes, e.g., E'\r\n'.
server closed the connection unexpectedly
The problem exists with
On 02/03/2010 10:18 AM, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
The problem exists with all three dblink_build_sql_* functions. Here is
a more complete patch. If there are no objections I'll apply this to
HEAD and look at back-patching -- these functions have hardly been
touched
[moving to hackers]
On 02/02/2010 10:23 PM, Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Should I also be looking to replace all (or most) other instances of
PQsetdbLogin()?
I think we at least wanted to fix pg_dump(all)/pg_restore. Not sure if
the others are worth troubling over
On 01/31/2010 09:42 AM, Guillaume Lelarge wrote:
I don't find that horrid. AFAICT, that's the only advantage of the
two-arrays method. By the way, it's that kind of code (keywords
declaration separated from values declaration) that got commited in the
previous patch
On 01/30/2010 01:14 PM, Dimitri Fontaine wrote:
Matteo Beccati p...@beccati.com writes:
I've been following the various suggestions. Please take a look at the
updated archives proof of concept:
http://archives.beccati.org/
I like the features a lot, and the only remarks I can think about
Last night I noted the following warning:
plperl.c: In function ‘plperl_create_sub’:
plperl.c:1117: warning: null argument where non-null required (argument 2)
I'm not familiar enough with this code to propose a fix...
Joe
signature.asc
Description: OpenPGP digital signature
On 01/28/2010 07:30 AM, Tim Bunce wrote:
On Thu, Jan 28, 2010 at 06:31:19AM -0800, Joe Conway wrote:
Last night I noted the following warning:
plperl.c: In function ‘plperl_create_sub’:
plperl.c:1117: warning: null argument where non-null required (argument 2)
The master branch of my git
On 01/27/2010 09:49 AM, Ivan Sergio Borgonovo wrote:
On Wed, 27 Jan 2010 17:37:23 +0200
Heikki Linnakangas heikki.linnakan...@enterprisedb.com wrote:
Currently, there's no difference in terms of memory needs. The
backend always materializes the result of a SRF into a tuplestore
anyway, if
On 01/26/2010 02:55 PM, Guillaume Lelarge wrote:
Le 26/01/2010 19:43, Joe Conway a écrit :
On 01/25/2010 03:21 PM, Guillaume Lelarge wrote:
I didn't put any documentation before knowing which one will be choosen.
So we still need to work on the manual.
Please send the documentation
On 01/25/2010 03:21 PM, Guillaume Lelarge wrote:
I didn't put any documentation before knowing which one will be choosen.
So we still need to work on the manual.
Please send the documentation as a separate patch. Once I have that I
will commit the posted patch, barring any objections in the
I'm reviewing the patch posted here:
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01579.php
for this commitfest item:
https://commitfest.postgresql.org/action/patch_view?id=259
Patch attached - a few minor changes:
-
1) Updated to apply cleanly
On 01/21/2010 11:19 PM, Heikki Linnakangas wrote:
Joe Conway wrote:
OK, so now I see why we want this fixed for dblink and walreceiver, but
doesn't this approach leave every other WIN32 libpq client out in the
cold? Is there nothing that can be done for the general case, or is it a
SMOP
On 01/11/2010 07:43 PM, Takahiro Itagaki wrote:
There is a memory leak in dblink when we cancel a query during
returning tuples. It could leak a PGresult because memory used
by it is not palloc'ed one. I wrote a patch[1] before, but I've
badly used global variables to track the resource.
On 01/21/2010 04:46 AM, Heikki Linnakangas wrote:
Heikki Linnakangas wrote:
Magnus Hagander wrote:
2010/1/17 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
We could replace the blocking PQexec() calls with PQsendQuery(), and use
the emulated version of select() to wait.
Hmm. That
On 01/21/2010 10:33 PM, Heikki Linnakangas wrote:
Joe Conway wrote:
I have not been really following this thread, but why can't we put the
#ifdef WIN32 and special definition of these functions into libpq. I
don't understand why we need special treatment for dblink.
The problem
On 01/11/2010 07:43 PM, Takahiro Itagaki wrote:
There is a memory leak in dblink when we cancel a query during
returning tuples. It could leak a PGresult because memory used
by it is not palloc'ed one. I wrote a patch[1] before, but I've
badly used global variables to track the resource.
On 01/12/2010 06:43 AM, Andrew Chernow wrote:
What is the point of this discussion? We're not going to remove the
facility for composite types, regardless of whether or not some people
regard them as unnecessary. And a name that better suits the task is
not to be sneered at anyway.
I
On 12/18/2009 04:09 PM, Tom Lane wrote:
At the moment it appears that we need the following hacks:
* ability to control the OIDs assigned to user tables and types.
Because a table also has a rowtype, this means at least two separate
state variables. And we already knew we had to control the
I'm trying to get PL/R binaries built on Windows, which I have not been
able to do successfully since the switch to Visual Studio from MinGW in
PostgreSQL 8.3. For some reason the MinGW PL/R binary does not load in
the VS compiled Postgres. Everything works if I also build PostgreSQL
with MinGW,
On 12/13/2009 10:48 AM, Magnus Hagander wrote:
2) If not, does anyone have a link for VS 2005? I haven't been able to
locate it on the MS site.
Yes. I'm unsure if they want that public or anything, so I'll send it
to you offlist :-)
Thanks!
3) Once I get Postgres compiling under VS, is
Tom Lane wrote:
Itagaki Takahiro itagaki.takah...@oss.ntt.co.jp writes:
I think PG_TRY blocks are not enough, too. PG_TRY requires a statement
block, but we need to return from dblink functions per tuple.
That bit will have to be undone. There is no reason for dblink not to
return a
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Given that change, is there even any leak to even worry about? As long
as the PGresult object is created in the correct memory context, it
ought to get cleaned up automatically, no?
No, because libpq knows nothing of backend memory
Robert Haas wrote:
On Mon, Oct 5, 2009 at 1:46 PM, Joe Conway m...@joeconway.com wrote:
I can't promise to make this change before 15 October, but I will get to
it before the end of CF3.
Another possibility is that Itagaki Takahiro, who developed the
original patch, might be willing
Itagaki Takahiro wrote:
The point is *memory leak* in dblink when a query is canceled or
become time-out. I think it is a bug, and my patch could fix it.
Please see if this works for you.
Joe
Index: dblink.c
===
RCS file:
Robert Haas wrote:
- There is one dblink pach left over from last CommitFest. Joe Conway
was going to review it the weekend of July 18th-19th, but that didn't
end up happening and so that patch is still waiting. We might be able
to find someone else to review it, but I'm not sure whether
Robert Haas wrote:
On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joe Conway m...@joeconway.com writes:
Robert Haas wrote:
- There is one dblink pach left over from last CommitFest. Joe Conway
was going to review it the weekend of July 18th-19th, but that didn't
end up
daveg wrote:
On Fri, Sep 18, 2009 at 01:04:23PM +0200, Hans-Juergen Schoenig -- PostgreSQL
wrote:
Tom,
On behalf of the entire PostgreSQL team here in Austria I want to wish
you a happy birthday.
We hope that you fill be a vital part of PostgreSQL for many years to come.
Best regards,
Itagaki Takahiro wrote:
Stephen Frost sfr...@snowman.net wrote:
Can you provide an update on this patch? Joe, you were going to
review and possibly commit it. Itagaki, did you have a new version?
Are there any outstanding issues?
Thanks for your reviewing.
Here is an updated
Itagaki Takahiro wrote:
Hi,
contrib/dblink doesn't transfar any non-error messages. Is it by design
or to be a ToDo item? We can use PQsetNoticeReceiver() here.
I never thought about or needed, and no one else ever asked...patch
welcomed.
Joe
signature.asc
Description: OpenPGP digital
Tom Lane wrote:
Pavel Stehule pavel.steh...@gmail.com writes:
2009/8/19 Tom Lane t...@sss.pgh.pa.us:
I don't believe there is any consensus for integrating dblink into core,
and I for one will resist that strongly. Â Keep it in contrib.
if integration means, so I could to write query like
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
Could you do something like
be_pid = pg_backend_pid() AS is_self_notify
instead, to verify that it's a self-notify? (This is not quite right
because you'd need to execute pg_backend_pid() at the remote end, but
I'm not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alvaro Herrera wrote:
Joe Conway escribió:
OK, how's this look?
Hmm, is it possible to use OUT parameters in the function instead of
declaring a new type for the result?
Sure, I guess I ought to use the latest-and-greatest. Any other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Sure, I guess I ought to use the latest-and-greatest. Any other comments
before I commit?
That be_pid/be_pid hack in the regression test is pretty ugly, and
doesn't test anything very
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In reference to:
http://archives.postgresql.org/message-id/6534f7ae0811181547v1dc1f096g6222e8273b461...@mail.gmail.com
Had to fix a lot of bit rot, but otherwise looks good. My updated patch
attached. Will commit in a day or so if no objections.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Alvaro Herrera wrote:
Joe Conway escribió:
2) It would be nice if the mail archive web page of the original message
had a Reply To button. Otherwise I guess I can do what I've done above.
I totally agree, but this is not workable given our
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
[ thinks for awhile... ] Actually, it seems to me that the present
patch's definition of the function would be very hard to work with.
You would normally want to work with the events one at a time.
There isn't much you could do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
[ thinks for awhile... ] Actually, it seems to me that the present
patch's definition of the function would be very hard to work with.
You would normally want to work with the events one at a time.
There isn't much you could do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Joe Conway wrote:
If there are no objections, I'll commit in a day or two.
Attached version committed. Only difference from the last is catversion.
Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'm testing pg_migrator, and running into an annoyance with timestamps
while trying to verify the conversion. My steps were:
install pg_migrator under 8.4 cluster
run pg_migrator in copy mode -- pg_migrator reports success
start up 8.4 cluster
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
1. Two functions were left in the 8.4 database
pg_toasttbl_drop(oid)
pg_toasttbl_recreate(oid, oid)
This is pg_migrator's fault --- it should probably clean those up
when it's
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In response to:
http://archives.postgresql.org/message-id/1238394513-21474-1-git-send-email-...@oryx.com
Review complete. Somewhat modified patch attached. I wasn't happy with
creation of verify_sequence_oid() when it more-or-less duplicates the
of them
- Heikki, Michael Meskes, Joe Conway - are away at the moment. About
25% of the remaining patches are waiting for one of those three people
to take the next step (as either patch author, or reviewer, or
committer).
Well, any commitfest is going to have some issues of that sort
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Forgive me if I'm missing something obvious, but...
I am signed up to review, for example:
https://commitfest.postgresql.org/action/patch_view?id=107
If I click on the link for patch, I go to here:
Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Consistency here is pointless. IIRC the dual method is used in contrib
because people did not trust the PGXS stuff enough to rip the original
Make code out; or maybe because people did not want PGXS to
Tom Lane wrote:
Please get this committed soon, we have other stuff to get done
(like a pgindent run).
Thanks -- committed.
Joe
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
how to trigger the failure (and therefore how to test the solution). A
naive test with two databases, one LATIN2, the other UTF8 does not
produce the error with simple text literals. Any guidance on specific
literals that would trigger
Based on Tom's post today about RC1, it sounds like I need to get this
committed very soon. Any complaints?
Joe
Original Message
Subject: Re: [HACKERS] dblink patches for comment
Date: Tue, 02 Jun 2009 16:08:18 -0700
From: Joe Conway m...@joeconway.com
Tom Lane wrote
Tom Lane wrote:
The quoting logic is still completely the wrong thing :-(. For one
thing, quote_literal will try to generate E'' syntax in some cases.
But more to the point, quote_literal's quoting rules don't match
what is needed. A look at libpq's conninfo_parse says that what it
accepts is
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Tom Lane wrote:
you will need to whip up a special-purpose quoting subroutine.
OK, I see that. I assume I need to care for encoding issues? If so, do I
assume server encoding or client encoding?
Hoo, good point. You can assume
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
OK, got it. I think the attached is what you're looking for, although I
have not yet tested beyond it compiles and it passes make installcheck.
You're making it vastly overcomplicated. Just do something like
for (cp = str; *cp
Tom Lane wrote:
But that reminds me, weren't you going to add something to force
libpq to set client_encoding to the database encoding?
I think the attached is what you had in mind. But I don't know right off
how to trigger the failure (and therefore how to test the solution). A
naive test
Tom Lane wrote:
The docs patch looks okay, except this comment is a bit hazy:
+ -- Note: local connection must require authentication for this to work
properly
I think what it means is
+ -- Note: local connection must require password authentication for this to
work properly
If not,
Tom Lane wrote:
Joe Conway m...@joeconway.com writes:
Probably better if I break this up in logical chunks too. This patch
only addresses the refactoring you requested here:
http://archives.postgresql.org/message-id/28719.1230996...@sss.pgh.pa.us
This looks sane to me in a quick once-over
Tom Lane wrote:
It's hard to review it without any docs that say what it's supposed to do.
(And you'd need to patch the docs anyway, eh?)
Fair enough :-)
Probably better if I break this up in logical chunks too. This patch
only addresses the refactoring you requested here:
Tom Lane wrote:
It's hard to review it without any docs that say what it's supposed to do.
(And you'd need to patch the docs anyway, eh?)
Here's a much simpler SQL/MED support patch for dblink.
This enforces security in the same manner for FOREIGN SERVER connections
as that worked out over
The attached addresses items#2 and 3 as listed by Bruce here:
http://momjian.us/cgi-bin/pgsql/joe
I think it is consistent with the discussions we had a PGCon last week.
Any objections to me committing this for 8.4?
On a side note, should I try to address items #1 #4 for 8.4 as well?
401 - 500 of 1244 matches
Mail list logo
