Joe Conway m...@joeconway.com writes:
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 with two databases, one LATIN2, the other UTF8 does not
produce the error with simple text
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 the
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
Joe Conway m...@joeconway.com writes:
Based on Tom's post today about RC1, it sounds like I need to get this
committed very soon. Any complaints?
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
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
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 the database (server)
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 the
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; cp++)
{
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
Joe Conway m...@joeconway.com writes:
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.
Looks plausible to me.
But I don't know right off
how to trigger the
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,
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, though I've not
Joe Conway m...@joeconway.com writes:
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 time for other dblink connections. Essentially,
the FOREIGN SERVER and associated user MAPPING
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
Joe Conway m...@joeconway.com writes:
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?
It's hard to review it without any
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?
20 matches
Mail list logo
