On Saturday, July 23, 2011, Christopher Browne cbbro...@gmail.com wrote:
I generally agree, Josh, but I think readline is getting pointed at a bit too
much. Yeah, it's a bad one, but we also include other stuff like zlib that
doesn't commonly come up as an issue.
I'd argue something just a
Robert Haas wrote:
On Fri, Jul 22, 2011 at 12:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Fri, Jul 22, 2011 at 12:13 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, if you read it that way, then CREATE USER MAPPING with an empty
option set is a no-op:
On 22 July 2011 22:28, Robert Haas robertmh...@gmail.com wrote:
On Fri, Jul 22, 2011 at 4:39 PM, Alvaro Herrera
alvhe...@commandprompt.com wrote:
Excerpts from Robert Haas's message of vie jul 22 12:14:30 -0400 2011:
On Thu, Jul 21, 2011 at 7:51 PM, Alvaro Herrera
alvhe...@commandprompt.com
On 07/22/2011 10:51 AM, Joshua D. Drake wrote:
On 07/21/2011 11:13 AM, Tom Lane wrote:
Joshua D. Drakej...@commandprompt.com writes:
So I am looking intently on what it is going to take to get the URI
patch done for psql [1] and was digging around the web and have a URI
parser library. It
On 07/22/2011 11:34 AM, Robert Haas wrote:
No, you can specify connection details at per-server and
per-foreign-table level too. The FDW implementation is free to accept or
reject options where-ever it wants.
Well, if we are going to take that viewpoint, then not having a user
mapping
On Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed dean.a.rash...@gmail.com wrote:
That looks wrong to me, because a NOT NULL constraint is a column
constraint not a table constraint. The CREATE TABLE syntax explicitly
distinguishes these 2 cases, and only allows NOT NULLs in column
constraints. So
Pg_upgrade writes temporary files (e.g. _dumpall output) into the
current directory, rather than a temporary directory or the user's home
directory. (This was decided by community discussion.)
I have a check in pg_upgrade 9.1 to make sure pg_upgrade has write
permission in the current directory:
On 07/23/2011 08:45 AM, Bruce Momjian wrote:
Pg_upgrade writes temporary files (e.g. _dumpall output) into the
current directory, rather than a temporary directory or the user's home
directory. (This was decided by community discussion.)
I have a check in pg_upgrade 9.1 to make sure
Andrew Dunstan wrote:
We do use access() in a few other places in our code, but not for
directory permission checks.
Any ideas on a solution? Will checking stat() work? Do I have to try
creating a dummy file and delete it?
That looks like the obvious solution - it's what came to my
On Sat, Jul 23, 2011 at 9:14 AM, Bruce Momjian br...@momjian.us wrote:
Andrew Dunstan wrote:
We do use access() in a few other places in our code, but not for
directory permission checks.
Any ideas on a solution? Will checking stat() work? Do I have to try
creating a dummy file and
Andrew Dunstan and...@dunslane.net writes:
What does the standard say?
Well, there is not a statement in so many words that you have to have a
relevant USER MAPPING to use a foreign table. But the spec does specify
that an FDW's ConnectServer function takes a UserHandle as one input
parameter
On 07/23/2011 10:42 AM, Tom Lane wrote:
Andrew Dunstanand...@dunslane.net writes:
What does the standard say?
Well, there is not a statement in so many words that you have to have a
relevant USER MAPPING to use a foreign table. But the spec does specify
that an FDW's ConnectServer function
Albe Laurenz laurenz.a...@wien.gv.at writes:
I don't like to think of a user mapping as a means to restrict access
to the foreign data source, because in effect that is the same as
restricting access to the foreign table, which is the ACL's job.
No, the standard is quite clear that those are
Andrew Dunstan and...@dunslane.net writes:
In that case I think I'm in favor of the suggestion of an implied empty
user mapping for PUBLIC, as long as it can be overridden.
But how would you do that (override it)? All you can do is create an
explicit mapping, and then you still have a mapping
Marc Munro m...@bloodnok.com writes:
In postgres 9.1 I have created 2 extensions, veil and veil_demo. When I
install veil, it creates a default (not very useful) version of a
function: veil_init().
When I create veil_demo, it replaces this version of the function with
it's own (useful)
Florian Pflug f...@phlo.org writes:
A variant of this would be to allow extensions (in the CREATE EXTENSION
sense) to declare custom GUCs in their control file. Then we'd only
need to load those files, which seems better than loading a shared
library.
The original patch for the extensions had
Hi
The current thread about JSON and the ensuing discussion about the
XML types' behaviour in non-UTF8 databases made me try out how well
XPATH() copes with that situation. The code, at least, looks
suspicious - XPATH neither verifies that the server encoding is UTF-8,
not does it pass the server
[Resent with pgsql-hackers re-added to the recipient list.
I presume you didn't remove it on purpose]
On Jul23, 2011, at 18:11 , Joey Adams wrote:
On Sat, Jul 23, 2011 at 11:49 AM, Florian Pflug f...@phlo.org wrote:
So what I think we should do is tell libxml that the encoding is ASCII
if the
On Sat, 2011-07-23 at 11:08 -0400, Tom Lane wrote:
If I drop the extension veil_demo, I am left with the veil_demo version
of veil_init().
Is this a feature or a bug? Is there a work-around?
Hmm. I don't think we have any code in there to prohibit the same
object from being made a
On 07/22/2011 05:00 PM, Josh Berkus wrote:
Arguments in favor of coding from scratch:
1) Does not introduce new dependencies into postgresql-client packages.
(note how much of a problem Readline has been)
Readline has license issues, this doesn't.
2) keeps psql as lightweight as possible
On 07/23/2011 03:39 AM, Andrew Dunstan wrote:
1. I think the proposed use is of very marginal value at best, and
certainly not worth importing an external library for.
2. Even if we have the feature, we do not need to parse URIs generally.
A small amount of hand written C code should suffice.
On lör, 2011-07-23 at 17:49 +0200, Florian Pflug wrote:
The current thread about JSON and the ensuing discussion about the
XML types' behaviour in non-UTF8 databases made me try out how well
XPATH() copes with that situation. The code, at least, looks
suspicious - XPATH neither verifies that
On 06/02/2011 05:27 PM, Tom Lane wrote:
Looks like we can't declare getpeereid on Windows anyway.
... for lack of the uid_t and gid_t typedefs. Per buildfarm.
This has given rise to a bunch of warnings on Windows. I'm confused
about how we can compile with a signature that includes
On Jul23, 2011, at 22:49 , Peter Eisentraut wrote:
On lör, 2011-07-23 at 17:49 +0200, Florian Pflug wrote:
The current thread about JSON and the ensuing discussion about the
XML types' behaviour in non-UTF8 databases made me try out how well
XPATH() copes with that situation. The code, at
On Mon, Jun 13, 2011 at 7:03 AM, Stefan Kaltenbrunner
ste...@kaltenbrunner.cc wrote:
On 06/13/2011 01:55 PM, Stefan Kaltenbrunner wrote:
[...]
all those tests are done with pgbench running on the same box - which
has a noticable impact on the results because pgbench is using ~1 core
per 8
Also, should I forbid the escape \u (in all database encodings)?
Pros:
* If \u is forbidden, and the server encoding is UTF-8, then
every JSON-wrapped string will be convertible to TEXT.
* It will be consistent with the way PostgreSQL already handles text,
and with the decision to use
On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams joeyadams3.14...@gmail.com wrote:
Interesting. This leads to a couple more questions:
* Should the JSON data type (eventually) have an equality operator?
+1.
* Should the JSON input function alphabetize object members by key?
I think it would
Robert Haas wrote:
On Sat, Jul 23, 2011 at 9:14 AM, Bruce Momjian br...@momjian.us wrote:
Andrew Dunstan wrote:
We do use access() in a few other places in our code, but not for
directory permission checks.
Any ideas on a solution? ?Will checking stat() work? ?Do I have to try
28 matches
Mail list logo
