Robert Haas wrote:
> On Sat, Jul 23, 2011 at 9:14 AM, Bruce Momjian 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
> >
On Fri, Jul 22, 2011 at 10:36 PM, Joey Adams 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 probably be better if i
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 Mon, Jun 13, 2011 at 7:03 AM, Stefan Kaltenbrunner
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 cores of the ba
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,
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 uid_t
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 tha
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. I
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 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
[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 wrote:
>> So what I think we should do is tell libxml that the encoding is ASCII
>> if the server en
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
Florian Pflug 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 that feat
Marc Munro 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) version.
> If I
Andrew Dunstan 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 that allows acces
"Albe Laurenz" 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 distinct things.
See
On 07/23/2011 10:42 AM, Tom Lane wrote:
Andrew Dunstan 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
Andrew Dunstan 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 and should throw an
On Sat, Jul 23, 2011 at 9:14 AM, Bruce Momjian 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 del
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
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 pg_upgrad
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 Sat, Jul 23, 2011 at 4:37 AM, Dean Rasheed 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 from a consistency p
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 *shou
On 07/22/2011 10:51 AM, Joshua D. Drake wrote:
On 07/21/2011 11:13 AM, Tom Lane wrote:
"Joshua D. Drake" 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 is under the New BSD l
On 22 July 2011 22:28, Robert Haas wrote:
> On Fri, Jul 22, 2011 at 4:39 PM, Alvaro Herrera
> 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
>>> wrote:
>>> >> I think that there probably ought to be a way to di
26 matches
Mail list logo
