On Wed, Sep 30, 2009 at 11:53 PM, Tom Lane wrote:
>
> Although come to think of it ... is there any reason besides sheer
> conservatism to not make the default listen_addresses value '*'?
just my 2 cents. but i always wondered about the existence of
listen_addresses at all... to me the only reaso
On 1 okt 2009, at 06.53, Tom Lane wrote:
Peter Eisentraut writes:
On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
(Note that you would still need a non-default setting of
listen_addresses for "-h machine_name" to actually work.)
Which makes this proposal kind of uninteresting.
Althou
Peter Eisentraut writes:
> On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
>> (Note that you would still need a non-default setting of
>> listen_addresses for "-h machine_name" to actually work.)
> Which makes this proposal kind of uninteresting.
Although come to think of it ... is there any
Peter Eisentraut writes:
>> (Note that you would still need a non-default setting of
>> listen_addresses for "-h machine_name" to actually work.)
> Which makes this proposal kind of uninteresting.
Well, it's one less thing that has to be fixed for local connections
to work smoothly.
> Plus, wit
On Wed, 2009-09-30 at 22:08 -0400, Tom Lane wrote:
> # local connections via TCP/IP:
> hostall all samehost @authmethod@
>
> The advantage of this is that connections made with "-h machine_name"
> instead of "-h localhost" would work without customization. I can't
On Wed, 2009-09-30 at 18:50 -0400, Tom Lane wrote:
> It would be a good idea to tie this to a psql magic variable (like
> ON_ERROR_STOP) so that it could conveniently be set in ~/.psqlrc.
> I'm not actually sure that we need a dedicated command line switch
> for it, since you could use "-v varname"
Mark Mielke writes:
> I would like to see the default of "trust" abolished.
We've been around on that point before and I don't see any reason to
think that the outcome of the argument would be different now. The only
reason I brought all this up is that "samehost" does change the terms of
debate
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > I'm not sure if it out-ranks the advantages of the change for buildfarm
> > support, but the above change isn't actually without any disadvantage.
> > Specifically, not every auth mechanism that works with -h machine_name
> > works
Robert Haas writes:
> I don't see much advantage in this proposal, at least not immediately.
> If it turns out to be a wildly popular feature and doesn't turn out
> to introduce security vulnerabilities or breakage, we can always make
> this change later.
The advantage is to get some testing so
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Stephen Frost wrote:
> > Thanks. To make sure it gets picked up, you might respond to Tom's
> > message above with this same email. Just a thought.
>
> The following message was my reply.
> http://archives.postgresql.org/pgsql-hackers/2009-08/msg0
Stephen Frost writes:
> I'm not sure if it out-ranks the advantages of the change for buildfarm
> support, but the above change isn't actually without any disadvantage.
> Specifically, not every auth mechanism that works with -h machine_name
> works with -h localhost, but the first record in pg_hb
Stephen Frost wrote:
> KaiGai,
>
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> The attached patch eliminates permission checks in FindConversion()
>> and EnableDisableRule(), because these are nonsense or redundant.
>>
>> It is an separated issue from the ac_*() routines.
>> For now, we decide
Stephen Frost wrote:
>>> I know it doesn't hide existence of major database objects. Depending
>>> on the situation, there might be other information that could be leaked.
>>> I realize that's not the case here, but I still want to catch and
>>> document any behavioral changes, even if it's clear
On 09/30/2009 10:08 PM, Tom Lane wrote:
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
# IPv4 local connections:
hostall all 127.0.0.1/32 @authmethod@
# IPv6 local connections:
h
Euler Taveira de Oliveira wrote:
> > But there are some confusions in postgres; ReadBufferCount and
> > BufferHitCount are used for "get" and "hit", but "heap_blks_read"
> > and "heap_blks_hit" are used for "read" and "hit" in pg_statio_all_tables.
> I see. :(
I fixed the confusions of get, hit
On Wed, Sep 30, 2009 at 10:08 PM, Tom Lane wrote:
> The advantage of this is that connections made with "-h machine_name"
> instead of "-h localhost" would work without customization. I can't
> see any disadvantage to it. Making the change now would also give
> us an opportunity to test the same
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Now that the samehost/samenet patch is in, I wonder if it wouldn't be
> a good idea to replace this part of the default pg_hba.conf file:
>
> # IPv4 local connections:
> hostall all 127.0.0.1/32 @authmethod@
> # IPv6 local conne
On Thu, Sep 17, 2009 at 5:08 PM, Heikki Linnakangas
wrote:
> Walreceiver is really a slave to the startup process. The startup
> process decides when it's launched, and it's the startup process that
> then waits for it to advance. But the way it's set up at the moment, the
> startup process needs
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Yes, it is reasonable both of MAC/DAC to handle temporary schema as
> an exception of access controls on schemas.
Great.
> > I know it doesn't hide existence of major database objects. Depending
> > on the situation, there might be other in
Magnus Hagander wrote:
> I can certainly review the win32 encoding patch, but I was rather
> hoping for some comments from others on if we're interested in a win32
> only solution, or if we want something more generic. Should we just go
> with the win32-only one for now?
Yes, because Windows is
Now that the samehost/samenet patch is in, I wonder if it wouldn't be
a good idea to replace this part of the default pg_hba.conf file:
# IPv4 local connections:
hostall all 127.0.0.1/32 @authmethod@
# IPv6 local connections:
hostall all ::1/128
Stef Walter writes:
> [ postgres-hba-samenet-8.patch ]
Applied with some mostly-cosmetic editorialization.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pg
Joe Conway wrote:
> The patch basically forces all use of libpq by dblink to be asynchronous
> (internally) so that a cancel can be sensed and passed down to the
> remote side and everything cleaned up. Possibly the right thing to do,
> but dblink already allows the use of async queries, and the
> Peter Eisentraut wrote:
> > If you want a "pretty" option on pg_get_triggerdef(), you could nowadays
> > also implement that via a parameter default value instead of a second
> > function.
>
> OK, I'll rewrite it to use default parameter.
I tried to remove pg_get_triggerdef_ext() and add a se
Stephen Frost wrote:
> * KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
>> Stephen Frost wrote:
>>> The scenario you outline could happen without SE-PG, couldn't it?
>>> Specifically, if a user makes a connection, creates a temporary table,
>>> and then their rights to create temporary tables are revok
Alvaro Herrera wrote:
> Hmm, so it works to specify LIKE t1 INCLUDING COMMENTS EXCLUDING COMMENTS?
Only last specifer is applied, which is the same behavior as of now.
EXCLUDING is typically useless because all of the default values are
EXCLUDING, but "INCLUDING ALL EXCLUDING xxx" are meaningf
Peter Eisentraut wrote:
> What is the purpose of the new pg_get_triggerdef() variant? OK, the
> parameter name "pretty_bool" gives a hint, but what does this have to do
> with column triggers? Maybe you could try to explain this in more
> detail. Ideally split the patch into two: one that dea
"Joshua D. Drake" wrote:
> On Wed, 2009-09-30 at 19:08 -0500, Kevin Grittner wrote:
>> I don't currently have access to an Oracle database
> Just download developer edition?
[quick google search]
Looks like that would do it. Thanks.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsq
On Wed, 2009-09-30 at 19:08 -0500, Kevin Grittner wrote:
> Tom Lane wrote:
> > "Kevin Grittner" writes:
> >> daveg wrote:
> >>> On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
> It seems that Oracle reads formatting string from right-to-left.
> >
> >>> It seems worse to to
Tom Lane wrote:
> "Kevin Grittner" writes:
>> daveg wrote:
>>> On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
It seems that Oracle reads formatting string from right-to-left.
>
>>> It seems worse to to give a wrong answer silently then to throw an
>>> error. What we do n
"Kevin Grittner" writes:
> daveg wrote:
>> On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
>>> It seems that Oracle reads formatting string from right-to-left.
>> It seems worse to to give a wrong answer silently then to throw an
>> error. What we do now seems sort of MySqlish.
daveg wrote:
> On Tue, Sep 22, 2009 at 10:27:19AM +0530, Jeevan Chalke wrote:
>>
>> It seems that Oracle reads formatting string from right-to-left.
>> Here are few results:
>> ('number','format') ==> Oracle PG
>>
>> ('34,50','999,99') ==> 3
> "Tom" == Tom Lane writes:
>> And there was much rejoicing
Tom> ... except in the buildfarm. Must be some platform dependency
Tom> we both missed ...
"oops"
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your sub
Roger Leigh writes:
>> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
>>> Thinking about this some more, ISTM a much better way of approaching
>>> it would be to provide a flag for psql to turn off the fancy
>>> formatting, and have pg_regress use that flag.
> The attached patch imple
decibel wrote:
> *any* step that improves dealing with table bloat is extremely
> welcome, as right now you're basically stuck rebuilding the table.
+1
Although, possibly more irritating than actually rebuilding it is
evaluating borderline bloat situations to determine if they will "work
th
Peter Eisentraut writes:
> On Wed, 2009-09-30 at 14:02 -0400, Alvaro Herrera wrote:
>> All scripts I've seen parsing psql output use unaligned, undecorated
>> mode. I have yet to see one messing with the |'s.
> Plus, we would have broken that with the : continuation lines.
Only for data contain
"David E. Wheeler" writes:
> On Sep 30, 2009, at 12:52 PM, Tom Lane wrote:
>> Applied with some mostly-cosmetic editorialization.
> And there was much rejoicing
... except in the buildfarm. Must be some platform dependency we both
missed ...
regards, tom lane
--
Sent
Tom Lane escribió:
> Alvaro Herrera writes:
> > FWIW I came up with a preliminary patch for a new psql command \dus that
> > shows settings. It takes a pattern that's used to constrain on roles.
> > Thus there is no way to view settings for a database. If there's a need
> > for that we could use
Joe Conway writes:
> The issue is not so much technical as it is philosophical.
> The patch basically forces all use of libpq by dblink to be asynchronous
> (internally) so that a cancel can be sensed and passed down to the
> remote side and everything cleaned up. Possibly the right thing to do,
On Sep 30, 2009, at 12:52 PM, Tom Lane wrote:
Applied with some mostly-cosmetic editorialization.
And there was much rejoicing…
David
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera writes:
> FWIW I came up with a preliminary patch for a new psql command \dus that
> shows settings. It takes a pattern that's used to constrain on roles.
> Thus there is no way to view settings for a database. If there's a need
> for that we could use another command, say \dls.
Tom Lane escribió:
> BTW, have we thought much about the simplest possible solution,
> which is to not have the view? How badly do we need it? Seems
> like dropping the functionality into a psql \d command might be
> a viable alternative.
FWIW I came up with a preliminary patch for a new psql c
Andrew Gierth writes:
> Hstore patch incorporating changes as previously discussed.
> In addition the requested new features of conversions to and from
> array formats have been added (with docs).
Applied with some mostly-cosmetic editorialization.
regards, tom lane
--
On Wed, Sep 30, 2009 at 21:38, Tom Lane wrote:
> Magnus Hagander writes:
>> I can certainly review the win32 encoding patch, but I was rather
>> hoping for some comments from others on if we're interested in a win32
>> only solution, or if we want something more generic. Should we just go
>> with
Robert Haas writes:
> The way it works right now (and has worked for the last 5 years or
> more) is reliable, familiar, and, at least IME, bullet-proof. I don't
> even see a good case for changing the default, let alone not providing
> a way to retreat to the old behavior.
This is pretty much my
Magnus Hagander writes:
> I can certainly review the win32 encoding patch, but I was rather
> hoping for some comments from others on if we're interested in a win32
> only solution, or if we want something more generic. Should we just go
> with the win32-only one for now?
That was actually the on
Hi all,
because it seems like merging privileges seems to be acceptable for most
(although I am not sure I like it, but I don't have better solution for
managing conflicts), I changed the patch to do just that.
Also I think I addressed all other problems pointed out by Tom. Namely I
added pg
On Wed, 2009-09-30 at 14:02 -0400, Alvaro Herrera wrote:
> All scripts I've seen parsing psql output use unaligned, undecorated
> mode. I have yet to see one messing with the |'s.
Plus, we would have broken that with the : continuation lines.
--
Sent via pgsql-hackers mailing list (pgsql-hacke
On Mon, 2009-09-14 at 18:58 +0900, Itagaki Takahiro wrote:
> Itagaki Takahiro wrote:
>
> > Ok, the attached patch implements standard-compliant version of
> > column trigger.
>
> Here is an updated version of column-level trigger patch.
> I forgot to adjust pg_get_triggerdef() in the previous ve
On Wed, Sep 30, 2009 at 01:30:17PM -0400, Andrew Dunstan wrote:
>
>
> Peter Eisentraut wrote:
>> On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
>>
>>> Thinking about this some more, ISTM a much better way of approaching
>>> it would be to provide a flag for psql to turn off the fancy
On Wed, Sep 30, 2009 at 1:27 PM, Peter Eisentraut wrote:
> On Wed, 2009-09-30 at 12:06 -0400, Robert Haas wrote:
>> On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane wrote:
>> > Andrew Dunstan writes:
>> >> Thinking about this some more, ISTM a much better way of approaching it
>> >> would be to provid
Magnus Hagander escribió:
> On Wed, Sep 30, 2009 at 18:34, Tom Lane wrote:
> > Robert Haas writes:
> >> ... (and many of the more
> >> significant remaining patches look like they are right up Tom's alley
> >> anyway).
> >
> > FWIW, if left to my own devices I will eventually get to everything
>
On Wed, Sep 30, 2009 at 18:34, Tom Lane wrote:
> Robert Haas writes:
>> ... (and many of the more
>> significant remaining patches look like they are right up Tom's alley
>> anyway).
>
> FWIW, if left to my own devices I will eventually get to everything
> except the dblink, ecpg, and encoding/wi
Andrew Dunstan escribió:
>
>
> Peter Eisentraut wrote:
> >On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
> >>Thinking about this some more, ISTM a much better way of
> >>approaching it would be to provide a flag for psql to turn off
> >>the fancy formatting, and have pg_regress use that
At 2009-09-30 11:16:57 -0500, stef-l...@memberwebs.com wrote:
>
> I've now added tests for sys/ioctl.h and net/if.h even though these
> headers seemed to be common to all the unixes investigated.
Thanks. I've marked this ready for committer now.
> FWIW, there are checks for various bad netmasks.
Robert Haas wrote:
> On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane wrote:
>> Joe Conway 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 happening and so t
On Wed, 2009-09-30 at 11:58 -0500, Kevin Grittner wrote:
> Right. It seems that, in addition to the above, there also remains
> some disagreement about:
>
> (1) how much checking the script should do to provide error messages
> and exit codes which target the specific problems versus generic "I
Peter Eisentraut wrote:
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have pg_regress use that flag.
Well, it might not be a b
On Wed, 2009-09-30 at 12:06 -0400, Robert Haas wrote:
> On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane wrote:
> > Andrew Dunstan writes:
> >> Thinking about this some more, ISTM a much better way of approaching it
> >> would be to provide a flag for psql to turn off the fancy formatting,
> >> and hav
On Wed, 2009-09-30 at 11:03 -0400, Andrew Dunstan wrote:
> Thinking about this some more, ISTM a much better way of approaching it
> would be to provide a flag for psql to turn off the fancy formatting,
> and have pg_regress use that flag.
Well, it might not be a bad idea, but adding a feature j
Robert Haas wrote:
On Wed, Sep 30, 2009 at 12:34 PM, Tom Lane wrote:
Robert Haas writes:
... (and many of the more
significant remaining patches look like they are right up Tom's alley
anyway).
FWIW, if left to my own devices I will eventually get to everything
except the db
On Wed, Sep 30, 2009 at 10:34 AM, Alvaro Herrera
wrote:
> And here's the last necessary bit, which is pg_dump support for all
> this.
I think it would be helpful if you could post ONE patch with all the
changes and all the new files in the diff. AIUI, "the" patch is now
split across three separa
On Wed, Sep 30, 2009 at 12:34 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... (and many of the more
>> significant remaining patches look like they are right up Tom's alley
>> anyway).
>
> FWIW, if left to my own devices I will eventually get to everything
> except the dblink, ecpg, and encoding
Robert Haas wrote:
> Peter Eisentraut wrote:
>> On Sun, 2009-09-20 at 22:54 -0400, Robert Haas wrote:
>>> It seems like there is some support for what this patch is trying
>>> to do, but much disagreement about the details of how to get
>>> there. Where do we go from here?
>>
>> I think the nex
On Wed, Sep 30, 2009 at 12:27 PM, Tom Lane wrote:
> Joe Conway 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 happening and so that patch is still waiting
Robert Haas writes:
> ... (and many of the more
> significant remaining patches look like they are right up Tom's alley
> anyway).
FWIW, if left to my own devices I will eventually get to everything
except the dblink, ecpg, and encoding/win32 patches. I don't intend
to touch any of those because
Joe Conway 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 happening and so that patch is still waiting. We might be able
>> to find someone else to review it,
Robert Haas wrote:
> On Wed, Sep 30, 2009 at 11:36 AM, Tom Lane wrote:
>> Heikki Linnakangas writes:
>>> OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
>>> should be returned to author at this point, I should move on to other
>>> patches to get the commitfest closed ASAP, and
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
Tom Lane wrote:
> I was just poking at this.
Thanks for trying it out.
It seems to need rather a lot of
> editorialization (eg to fix the lack of consistency about whether
> nonstandard headers have configure tests, or bother to make use of the
> tests that did get added).
I've now added tes
Robert Haas wrote:
On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane wrote:
Andrew Dunstan writes:
Thinking about this some more, ISTM a much better way of approaching it
would be to provide a flag for psql to turn off the fancy formatting,
and have pg_regress use that flag.
Yeah,
Alvaro Herrera writes:
> Tom Lane escribió:
>> Hmm ... I would kind of think that --roles-only should suppress this too.
>> Otherwise you're going to be dumping commands that might refer to
>> nonexistent databases.
> Hmm. The problem I have with this idea is that the only way to dump the
> per-
On Wed, Sep 30, 2009 at 11:11 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> Thinking about this some more, ISTM a much better way of approaching it
>> would be to provide a flag for psql to turn off the fancy formatting,
>> and have pg_regress use that flag.
>
> Yeah, that's not a bad idea. Th
On Wed, Sep 30, 2009 at 11:36 AM, Tom Lane wrote:
> Heikki Linnakangas writes:
>> OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
>> should be returned to author at this point, I should move on to other
>> patches to get the commitfest closed ASAP, and continue reviewing and
>>
Tom Lane escribió:
> Alvaro Herrera writes:
> > And here's the last necessary bit, which is pg_dump support for all
> > this.
>
> > + /* Dump role/database settings */
> > + if (!tablespaces_only)
> > + {
> > + if (server_version >= 80500)
> > +
Tom Lane escribió:
> Alvaro Herrera writes:
> > And here's the last necessary bit, which is pg_dump support for all
> > this.
>
> > + /* Dump role/database settings */
> > + if (!tablespaces_only)
> > + {
> > + if (server_version >= 80500)
> > +
Regarding this in InitStandbyDelayTimers:
+ /*
+* If replication delay is enormously huge, just treat that as
+* zero and work up from there. This prevents us from acting
+* foolishly when replaying old log files.
+*/
+ if (*currentDelay_ms < 0)
+ *currentDelay_ms = 0;
+
Heikki Linnakangas writes:
> OTOH, I'd hate to hold the commitfest hostage for that. Perhaps it
> should be returned to author at this point, I should move on to other
> patches to get the commitfest closed ASAP, and continue reviewing and
> polishing that right after the commitfest.
FWIW, I'd ra
Alvaro Herrera writes:
> And here's the last necessary bit, which is pg_dump support for all
> this.
> + /* Dump role/database settings */
> + if (!tablespaces_only)
> + {
> + if (server_version >= 80500)
> + dump
Robert Haas wrote:
> - Hot Standby and Streaming Replication are both huge new features in
> this CommitFest, and there seems to be a fair amount of activity
> around both patches. Heikki previously expressed optimism about
> getting Hot Standby done this CommitFest, but I am not sure whether he
>
Andrew Dunstan writes:
> Thinking about this some more, ISTM a much better way of approaching it
> would be to provide a flag for psql to turn off the fancy formatting,
> and have pg_regress use that flag.
Yeah, that's not a bad idea. There are likely to be other client
programs that won't wan
Roger Leigh writes:
> The language in SUSv2 in fact explicitly states that this is
> allowed. In fact, I've seen documentation that some UNIX systems such
> as HPUX already do have a UTF-8 C locale as an option.
I don't argue with the concept of a C.UTF8 locale --- in fact I think
it sounds pret
Andrew Dunstan wrote:
Roger Leigh wrote:
Here we just force the locale to C. This does have the disadvantage
that --no-locale is made redundant, and any tests which are dependent
upon locale (if any?) will be run in the C locale.
That is not a solution. We have not that long ago gone
On Tue, Sep 29, 2009 at 04:32:49PM -0400, Tom Lane wrote:
> Roger Leigh writes:
> >> C locale means POSIX behavior and nothing but.
>
> > Indeed it does. However, making LC_CTYPE be UTF-8 rather than
> > ASCII is both possible and still strictly conforming to the
> > letter of the standard. The
Andrew Dunstan writes:
> Roger Leigh wrote:
>> Here we just force the locale to C. This does have the disadvantage
>> that --no-locale is made redundant, and any tests which are dependent
>> upon locale (if any?) will be run in the C locale.
> That is not a solution.
Right. I think you may hav
Roger Leigh wrote:
Here we just force the locale to C. This does have the disadvantage
that --no-locale is made redundant, and any tests which are dependent
upon locale (if any?) will be run in the C locale.
That is not a solution. We have not that long ago gone to some lengths
to prov
On Tue, Sep 29, 2009 at 04:28:57PM -0400, Tom Lane wrote:
> Peter Eisentraut writes:
> > On Tue, 2009-09-29 at 12:01 -0400, Tom Lane wrote:
> >> The bigger question is exactly how we expect this stuff to interact with
> >> pg_regress' --no-locale switch. We already do clear all these variables
>
And here's the last necessary bit, which is pg_dump support for all
this.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
*** src/bin/pg_dump/pg_dumpall.c 11 Jun 2009 14:49:07 - 1.126
--- src/b
Peter Eisentraut writes:
> On Mon, 2009-09-28 at 10:44 -0700, John Naylor wrote:
>> + errmsg("statement FETCH returns more rows."),
>> + errhint("Multirows fetch are not allowed in PL/pgSQL.")));
>>
>> This might sound better as "statement FETCH returns multiple rows.",
> errmsg should be withou
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> The attached patch eliminates permission checks in FindConversion()
> and EnableDisableRule(), because these are nonsense or redundant.
>
> It is an separated issue from the ac_*() routines.
> For now, we decided not to touch these stuffs in
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Stephen Frost wrote:
> > The scenario you outline could happen without SE-PG, couldn't it?
> > Specifically, if a user makes a connection, creates a temporary table,
> > and then their rights to create temporary tables are revoked? What
> > should hap
On Mon, 2009-09-28 at 10:44 -0700, John Naylor wrote:
> +
> errmsg("statement FETCH returns more rows."),
> +
> errhint("Multirows fetch are not allowed in PL/pgSQL.")));
>
> This might sound better as "statement FETCH returns multiple rows.",
errmsg should be without period.
> and "Multirow
92 matches
Mail list logo
