On Mon, Jun 28, 2010 at 9:54 AM, Robert Haas wrote:
> This seems useful to me so here's a patch to implement it.
+1
This would be very useful for people who want to give a clusterware
control of postgres.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Softw
Robert Haas writes:
> It looks like the recent keepalives patch won't support MacOS X,
> because MacOS X does not have the TCP_KEEPIDLE, TCP_KEEPINTVL, and
> TCP_KEEPCNT socket parameters. It does have this:
It looks to me like there's support for setting KEEPIDLE and KEEPINTVL
via sysctl, but o
On Tue, Jun 29, 2010 at 4:07 AM, Robert Haas wrote:
> It looks like the recent keepalives patch won't support MacOS X,
> because MacOS X does not have the TCP_KEEPIDLE, TCP_KEEPINTVL, and
> TCP_KEEPCNT socket parameters. It does have this:
>
> #define TCP_KEEPALIVE 0x10 /* idle time
Yes, I went ahead and tried the original suggestion.
Here is what the added function went in as:
CREATE OR REPLACE FUNCTION xml_is_ok(x text)
RETURNS boolean AS
$BODY$
BEGIN
PERFORM XMLPARSE( DOCUMENT x::XML );
RETURN TRUE;
EXCEPTION WHEN OTHERS THEN
RETURN FALSE;
END;
$BODY$
LANGUAGE 'plp
On Mon, Jun 28, 2010 at 11:03 AM, Mike Berrow wrote:
> Is there some way to use the new, core XML functionality to simply return a
> truth value
> in the way that we need?.
Have you tried using a wrapper function like the one suggested
independently by Mike Rylander and David Fetter upthread? If
2010/6/28 KaiGai Kohei :
> Sorry, I couldn't understand some of idiomatic expressions, but you are
> saying that we have many variations of syscaches, so it is nonsense to
> wrap up all the usecases of them, but being worthful to focus on major
> usecases, such as name to oid translation, aren't yo
(2010/06/29 3:52), Robert Haas wrote:
> On Mon, Jun 28, 2010 at 1:00 PM, Tom Lane wrote:
>>> Another, and related idea that I had while looking at this is that a
>>> lot of object types could benefit from a get_whatever_heaptuple()
>>> function with the same calling syntax. get_whatever_oid() cou
Peter Eisentraut writes:
> Why are we using RTLD_GLOBAL?
Some guy named Eisentraut wanted it for plpython:
http://archives.postgresql.org/pgsql-hackers/2001-05/msg00563.php
http://archives.postgresql.org/pgsql-committers/2001-05/msg00283.php
Possibly that no longer applies, though. In general i
Magnus Hagander writes:
> On Mon, Jun 28, 2010 at 22:39, Tom Lane wrote:
>> I had in mind just legislating that the defaults are the RFC values,
>> none of this "try to use the registry values in one case" business.
> Um, if you look at that patch, it doesn't try to use the registry. It
> falls
On fre, 2010-06-25 at 18:57 -0400, Peter Eisentraut wrote:
> On fre, 2010-06-25 at 23:44 +0200, Andres Freund wrote:
> > Has anybody actually researched if it is safe to run python2 and
> > python3 in the same address space?
>
> You can't run plpython2 and plpython3 in the same session, because th
On 29/06/10 04:48, Tom Lane wrote:
"Ross J. Reedstrom" writes:
Hmm, I'm suddenly struck by the idea of having a max_cost parameter,
that refuses to run (or delays?) queries that have "too high" a cost.
That's been suggested before, and shot down on the grounds that the
planner's cost
Tom Lane wrote:
> Bruce Momjian writes:
> > Josh Berkus wrote:
> >>> You could argue it either way. The number of beta testers with
> >>> plpython3 installations is probably very small, so I'm kinda leaning to
> >>> just changing the code without a catversion bump. OTOH, if we want to
> >>> enco
Bruce Momjian writes:
> Josh Berkus wrote:
>>> You could argue it either way. The number of beta testers with
>>> plpython3 installations is probably very small, so I'm kinda leaning to
>>> just changing the code without a catversion bump. OTOH, if we want to
>>> encourage testing of pg_upgrade
We need to make extensive use of the 'xml_is_well_formed' function provided
by the XML2 module.
Yet the documentation says that the xml2 module will be deprecated since
"XML syntax checking and XPath queries"
is covered by the XML-related functionality based on the SQL/XML standard in
the core ser
Josh Berkus wrote:
>
> > You could argue it either way. The number of beta testers with
> > plpython3 installations is probably very small, so I'm kinda leaning to
> > just changing the code without a catversion bump. OTOH, if we want to
> > encourage testing of pg_upgrade ...
>
> FWIW, the las
Jesper Krogh wrote:
> I have not hit any issues with the work_mem being too high, but
> I'm absolutely sure that I could flood the system if they happened
> to be working at the same time.
OK, now that I understand your workload, I agree that a connection
pool at the transaction level won't do
On Mon, Jun 28, 2010 at 22:39, Tom Lane wrote:
> Magnus Hagander writes:
>> Here's what I'm thinking, for the libpq side. Similar change on the
>> server side. Seems ok?
>
> I had in mind just legislating that the defaults are the RFC values,
> none of this "try to use the registry values in one
Magnus Hagander writes:
> Here's what I'm thinking, for the libpq side. Similar change on the
> server side. Seems ok?
I had in mind just legislating that the defaults are the RFC values,
none of this "try to use the registry values in one case" business.
I don't believe that you can make the ser
On Mon, Jun 28, 2010 at 21:10, Magnus Hagander wrote:
> On Mon, Jun 28, 2010 at 21:03, Tom Lane wrote:
>> Magnus Hagander writes:
>>> On Mon, Jun 28, 2010 at 20:45, Tom Lane wrote:
I vote for #2. It's the least inconsistent --- we don't pay attention
to the registry for much of anyth
On 2010-06-28 21:24, Kevin Grittner wrote:
Jesper Krogh wrote:
Sorry if I'm asking silly questions, but how does transactions and
connection pooler's interact?
That depends a great deal on the pooler and its configuration, as
well as your client architecture. Our shop gathers up t
Robert Haas writes:
> On Mon, Jun 28, 2010 at 3:44 PM, Tom Lane wrote:
>> It would be better not to branch until we're certain we won't need to
>> re-wrap the beta. I'm wondering why you see a need for any daylight at
>> all between the branch date and the start of the CF.
> Well, I guess it is
The way I see it, we have two options:
1) Read the default value from the registry. That's some fairly ugly code, imho.
It seems faily simple to yank these values out, no? Even easier if you
use the all-in-wonder shell function SHGetValue().
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Ser
On Mon, Jun 28, 2010 at 3:44 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 28, 2010 at 3:23 PM, Josh Berkus wrote:
>>> Well, do you consider 7/8 to be mid-July or "close to the beginning"?
>
>> 7/8 would be about the last date I'd consider reasonable, given a CF
>> starting 7/15. I w
Robert Haas writes:
> On Mon, Jun 28, 2010 at 3:23 PM, Josh Berkus wrote:
>> Well, do you consider 7/8 to be mid-July or "close to the beginning"?
> 7/8 would be about the last date I'd consider reasonable, given a CF
> starting 7/15. I would prefer a few days earlier, but I'm not sure
> how mu
On Fri, Jun 25, 2010 at 5:07 PM, Robert Haas wrote:
> I spend a little bit of time analyzing this today and it appears to me
> that all of the calls to emode_for_corrupt_record() arrive via
> ReadRecord(), which itself takes an emode argument that is always
> passed by the caller as either LOG or
On Mon, Jun 28, 2010 at 3:32 PM, Josh Berkus wrote:
>> 7/8 would be about the last date I'd consider reasonable, given a CF
>> starting 7/15. I would prefer a few days earlier, but I'm not sure
>> how much of a vote I get considering that I'm not actively involved in
>> the release process or the
> 7/8 would be about the last date I'd consider reasonable, given a CF
> starting 7/15. I would prefer a few days earlier, but I'm not sure
> how much of a vote I get considering that I'm not actively involved in
> the release process or the packaging of installers.
Well, I think realistically w
On Mon, Jun 28, 2010 at 3:23 PM, Josh Berkus wrote:
>
>> At PGCon, the plan we discussed was to branch the tree on 7/1 and
>> start the next CommitFest on 7/15. If beta3 is going to happen
>> relatively close to the beginning of July, it might make sense to
>> create the new branch just after we
Jesper Krogh wrote:
> Sorry if I'm asking silly questions, but how does transactions and
> connection pooler's interact?
That depends a great deal on the pooler and its configuration, as
well as your client architecture. Our shop gathers up the
information needed for our database transaction
> At PGCon, the plan we discussed was to branch the tree on 7/1 and
> start the next CommitFest on 7/15. If beta3 is going to happen
> relatively close to the beginning of July, it might make sense to
> create the new branch just after we wrap beta3. But if we're not
> going to wrap beta3 until
It seems faily simple to yank these values out, no? Even easier if you use
the all-in-wonder shell function SHGetValue().
We don't want to use that function, because it brings in a bunch of
extra dependencies. This makes libpq.dll more heavyweight and more
importantly, decreases the number o
Josh Berkus writes:
> While I would personally prefer to have an operator for the slicing
> opeeration, I'm not willing to spend time arguing about it. So, +1 to
> implement the subset operation as the function slice(), and defer having
> an operator until later.
Yeah, I think the consensus is t
On Mon, Jun 28, 2010 at 21:03, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Jun 28, 2010 at 20:45, Tom Lane wrote:
>>> I vote for #2. It's the least inconsistent --- we don't pay attention
>>> to the registry for much of anything else, do we?
>
>> Directly, no? Indirectly, we do. For ev
On Mon, Jun 28, 2010 at 21:03, Andrew Chernow wrote:
>
>>
>> The way I see it, we have two options:
>> 1) Read the default value from the registry. That's some fairly ugly code,
>> imho.
>
> It seems faily simple to yank these values out, no? Even easier if you use
> the all-in-wonder shell funct
It looks like the recent keepalives patch won't support MacOS X,
because MacOS X does not have the TCP_KEEPIDLE, TCP_KEEPINTVL, and
TCP_KEEPCNT socket parameters. It does have this:
#define TCP_KEEPALIVE 0x10/* idle time used when
SO_KEEPALIVE is enabled */
Should we try to support
Robert Haas writes:
> At PGCon, the plan we discussed was to branch the tree on 7/1 and
> start the next CommitFest on 7/15. If beta3 is going to happen
> relatively close to the beginning of July, it might make sense to
> create the new branch just after we wrap beta3.
Seems reasonable. The 7/
Magnus Hagander writes:
> On Mon, Jun 28, 2010 at 20:45, Tom Lane wrote:
>> I vote for #2. It's the least inconsistent --- we don't pay attention
>> to the registry for much of anything else, do we?
> Directly, no? Indirectly, we do. For every other TCP parameter
> (because the registry control
On Mon, Jun 28, 2010 at 2:56 PM, Tom Lane wrote:
> Josh Berkus writes:
>> On 6/28/10 11:52 AM, Marc G. Fournier wrote:
>>> Why not do prep work with a release on the 5th?
>
>> I think that a bunch of the people needed for wraps are Americans. No?
>
> In any case, you won't get much attention for
On Mon, 28 Jun 2010, Josh Berkus wrote:
On 6/28/10 11:52 AM, Marc G. Fournier wrote:
Why not do prep work with a release on the 5th?
I think that a bunch of the people needed for wraps are Americans. No?
I'm not sure of all our nationalities .. I'm in Canada, Dave is in EU ...
I *think*
Josh Berkus writes:
> On 6/28/10 11:52 AM, Marc G. Fournier wrote:
>> Why not do prep work with a release on the 5th?
> I think that a bunch of the people needed for wraps are Americans. No?
In any case, you won't get much attention for an announcement on the
5th. Better to wait a week.
On Mon, Jun 28, 2010 at 2:26 PM, Tom Lane wrote:
> Robert Haas writes:
>> ... It is even more unreasonable to commit to
>> providing a timely patch (twice) and then fail to do so. We are
>> trying to finalize a release here, and you've made it clear you think
>> this code needs revision before t
On 6/28/10 11:52 AM, Marc G. Fournier wrote:
>
> Why not do prep work with a release on the 5th?
I think that a bunch of the people needed for wraps are Americans. No?
--
-- Josh Berkus
PostgreSQL Experts Inc.
Why not do prep work with a release on the 5th?
On Mon, 28 Jun 2010, Tom Lane wrote:
Josh Berkus writes:
Therefore, I propose that we set a beta3 release date for July 8th.
That should give it enough space from the American Holiday.
You mean wrap on Thursday the 8th for release on Monday t
On Mon, Jun 28, 2010 at 1:00 PM, Tom Lane wrote:
>> Another, and related idea that I had while looking at this is that a
>> lot of object types could benefit from a get_whatever_heaptuple()
>> function with the same calling syntax. get_whatever_oid() could be
>> restructured to use it, and most o
On Mon, Jun 28, 2010 at 20:45, Tom Lane wrote:
> Magnus Hagander writes:
>> [ can't read system's keepalive values in windows ]
>
>> The way I see it, we have two options:
>> 1) Read the default value from the registry. That's some fairly ugly code,
>> imho.
>> 2) Ignore the registry value and u
All,
>> I don't much like hstore(hstore, text[]) because it's not strictly a
>> constructor. But I could certainly live with something based on the
>> word slice. The existing SQL function backing the operator is called
>> slice_hstore(), whereas I would probably prefer hstore_slice() or just
>>
Magnus Hagander writes:
> [ can't read system's keepalive values in windows ]
> The way I see it, we have two options:
> 1) Read the default value from the registry. That's some fairly ugly code,
> imho.
> 2) Ignore the registry value and use the default value of 2 hours/1
> second. That will ov
On 6/28/10 11:40 AM, Tom Lane wrote:
> Josh Berkus writes:
>> Therefore, I propose that we set a beta3 release date for July 8th.
>> That should give it enough space from the American Holiday.
>
> You mean wrap on Thursday the 8th for release on Monday the 12th?
> That'd be fine with me. Actual
Josh Berkus writes:
> Therefore, I propose that we set a beta3 release date for July 8th.
> That should give it enough space from the American Holiday.
You mean wrap on Thursday the 8th for release on Monday the 12th?
That'd be fine with me. Actual release on the 8th would mean asking
people to
On 2010-06-25 22:44, Robert Haas wrote:
On Fri, Jun 25, 2010 at 3:52 PM, Kevin Grittner
wrote:
Heck, I think an even *more* trivial admission control policy which
limits the number of active database transactions released to
execution might solve a lot of problems.
That wouldn't hav
Folks,
There have been quite a number of fixes since Beta2. If we're going to
make a summer release date at all, we need to get moving.
Therefore, I propose that we set a beta3 release date for July 8th.
That should give it enough space from the American Holiday.
This would imply, of course, th
Robert Haas writes:
> ... It is even more unreasonable to commit to
> providing a timely patch (twice) and then fail to do so. We are
> trying to finalize a release here, and you've made it clear you think
> this code needs revision before then. I respect your opinion, but not
> your right to ma
Hi!
I'm looking at adding win32 support for keepalives in libpq (well,
also backend, but libpq for now), per the request from Robert Haas.
I've come up with one issue though - in Windows, you can only set the
"idle" and "interval" parameter together in a single syscall (in Unix,
you have one for e
Josh Berkus wrote:
> We can go back to Kevin's originally proposed simple feature:
> just allowing the DBA to limit the number of concurrently
> executing queries by role and overall.
Well, that's more sophisticated than what I proposed, but it's an
interesting twist on it.
> This would cons
While this does have the advantage of being relatively simple to
implement, I think it would be a bitch to tune...
Precisely. So, there's a number of issues to solve here:
1) We'd need to add accouting for total memory usage to explain plans
(worth doing on its own, really, even without adm
On Mon, Jun 28, 2010 at 10:19 AM, Tom Lane wrote:
> Simon Riggs writes:
>> On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
>>> Sorry, I've been a bit distracted by other responsibilities (libtiff
>>> security issues for Red Hat, if you must know). I'll get on it shortly.
>
>> I don't think th
It will get done. It is not the very first thing on my to-do list.
??? What is then?
If it's not the first thing on your priority list, with 9.0 getting
later by the day, maybe we should leave it to Robert and Simon, who *do*
seem to have it first on *their* list?
I swear, when Simon wa
Robert Haas writes:
> On Mon, Jun 28, 2010 at 12:31 PM, Tom Lane wrote:
>> Well, the whatever_exists() things would just be one-liner macros
>> declared in the same headers that declare the underlying
>> get_whatever_oid() functions. So the cost of carrying ones that happen
>> to not be used wou
"Ross J. Reedstrom" writes:
> Hmm, I'm suddenly struck by the idea of having a max_cost parameter,
> that refuses to run (or delays?) queries that have "too high" a cost.
That's been suggested before, and shot down on the grounds that the
planner's cost estimates are not trustworthy enough to rel
On Mon, Jun 28, 2010 at 12:31 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 28, 2010 at 12:17 PM, Tom Lane wrote:
>>> True. Is it worth providing whatever_exists() macros that wrap
>>> get_whatever_oid() like this, just so that callers are a bit clearer as
>>> to what they're doing?
Robert Haas wrote:
On Mon, Jun 28, 2010 at 11:42 AM, Mike Rylander wrote:
You could do something like this (untested):
CREATE OR REPLACE FUNCTION my_xml_is_valid ( x TEXT ) RETURNS BOOL AS $$
BEGIN
PERFORM XMLPARSE( DOCUMENT x::XML );
RETURN TRUE;
EXCEPTION WHEN OTHERS THEN
RETURN FALSE;
Robert Haas writes:
> On Mon, Jun 28, 2010 at 12:17 PM, Tom Lane wrote:
>> True. Is it worth providing whatever_exists() macros that wrap
>> get_whatever_oid() like this, just so that callers are a bit clearer as
>> to what they're doing?
> I haven't made a detailed study of this issue, so I'm
On Mon, Jun 28, 2010 at 12:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Jun 28, 2010 at 10:53 AM, Tom Lane wrote:
>>> I'm not sure I agree that replacing SearchSysCacheExists calls (or
>>> things that should have been SearchSysCacheExists calls) with
>>> OidIsValid(get_whatever_oid())
Robert Haas writes:
> On Mon, Jun 28, 2010 at 10:53 AM, Tom Lane wrote:
>> I'm not sure I agree that replacing SearchSysCacheExists calls (or
>> things that should have been SearchSysCacheExists calls) with
>> OidIsValid(get_whatever_oid()) is an improvement. The Exists call
>> tells what you're
On Mon, Jun 28, 2010 at 11:42 AM, Mike Rylander wrote:
> You could do something like this (untested):
>
> CREATE OR REPLACE FUNCTION my_xml_is_valid ( x TEXT ) RETURNS BOOL AS $$
> BEGIN
> PERFORM XMLPARSE( DOCUMENT x::XML );
> RETURN TRUE;
> EXCEPTION WHEN OTHERS THEN
> RETURN FALSE;
> END;
>
On Mon, Jun 28, 2010 at 10:53 AM, Tom Lane wrote:
> Robert Haas writes:
>> 2010/6/28 KaiGai Kohei :
>>> * at the RenameSchema()
>
>> This looks like another syscache reference leak.
>
> Actually that one *is* a leak, although it doesn't matter much because
> the leak occurs only in an error path,
On Mon, Jun 28, 2010 at 08:08:53AM -0700, Mike Berrow wrote:
> We need to make extensive use of the 'xml_is_well_formed' function provided
> by the XML2 module.
>
> Yet the documentation says that the xml2 module will be deprecated since
> "XML syntax checking and XPath queries"
> is covered by th
On Sat, Jun 26, 2010 at 01:19:57PM -0400, Robert Haas wrote:
>
> I'm not sure. What does seem clear is that it's fundamentally at odds
> with the "admission control" approach Kevin is advocating. When you
> start to run short on a resource (perhaps memory), you have to decide
> between (a) waiti
On Mon, Jun 28, 2010 at 10:48 AM, Tom Lane wrote:
> Robert Haas writes:
>> I agree, done. In fact, aren't we leaking a syscache reference here?
>
> How so? There's a ReleaseSysCache call.
Oops, you're right.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Com
On Mon, Jun 28, 2010 at 11:08 AM, Mike Berrow wrote:
> We need to make extensive use of the 'xml_is_well_formed' function provided
> by the XML2 module.
> Yet the documentation says that the xml2 module will be deprecated since
> "XML syntax checking and XPath queries"
> is covered by the XML-rela
I wrote:
> When preparing to deal with a new statement:
> - acquire lockX
> - if not a superuser
> - and not in an active transaction
> - and countX >= max_active_transactions
> - place current process at tail of waitX queue, and block
> - (lockX would be released while blocked)
> - in
Tom Lane wrote:
In a more abstract sense, what this would be is basically a custom
label for a dump file. I could see that being useful, but if we
wanted to support it then it ought to be an actual Feature and not
a kluge like this. Something like
pg_dump --label 'any string' ... oth
The thread on Admission Control caused me to realize that one policy
I'd been considering as a possibly useful second tier (execution)
admission control policy was actually more appropriate as a first
tier (simple) admission control policy. The difference (as defined
in the Hellerstein, Stonebrake
We need to make extensive use of the 'xml_is_well_formed' function provided
by the XML2 module.
Yet the documentation says that the xml2 module will be deprecated since
"XML syntax checking and XPath queries"
is covered by the XML-related functionality based on the SQL/XML standard in
the core ser
Robert Haas writes:
> 2010/6/28 KaiGai Kohei :
>> * at the RenameSchema()
> This looks like another syscache reference leak.
Actually that one *is* a leak, although it doesn't matter much because
the leak occurs only in an error path, so transaction abort will clean
up the leaked reference. Sti
Robert Haas writes:
> I agree, done. In fact, aren't we leaking a syscache reference here?
How so? There's a ReleaseSysCache call.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.
Simon Riggs writes:
> On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
>> Sorry, I've been a bit distracted by other responsibilities (libtiff
>> security issues for Red Hat, if you must know). I'll get on it shortly.
> I don't think the PostgreSQL project should wait any longer on this. If
>
Andrew Dunstan writes:
> Tom Lane wrote:
echo 'some custom header' >pg.dump
pg_dump -Fc >>pg.dump
> IIRC pg_restore expects the archive to begin with the header and TOC
> produced by pg_dump. Maybe I'm being dense, but I'm not able to see how
> prefixing that with something else could
On Mon, Jun 28, 2010 at 3:17 AM, Simon Riggs wrote:
> On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
>> Robert Haas writes:
>> > On Wed, Jun 9, 2010 at 8:01 PM, Tom Lane wrote:
>> >> Yes, I'll get with it ...
>>
>> > Any update on this?
>>
>> Sorry, I've been a bit distracted by other respon
On Fri, Jun 25, 2010 at 2:49 PM, Peter Eisentraut wrote:
> On fre, 2010-06-25 at 10:17 -0400, Tom Lane wrote:
>> Peter Eisentraut writes:
>> > The problem is apparently that when CREATE LANGUAGE creates a language
>> > from a pg_pltemplate entry, it creates the proname from the tmplhandler
>> > n
On Sun, Jun 27, 2010 at 9:02 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Thu, Jun 17, 2010 at 7:25 PM, Tom Lane wrote:
>>> Then all you need is a tweak to make the postmaster exit(1) after
>>> a crash instead of trying to launch recovery.
>
>> This seems useful to me so here's a patch to imp
Tom Lane wrote:
Andrew Dunstan writes:
Tom Lane wrote:
A somewhat more plausible scenario is that somebody might hope that
they could do something like this:
echo 'some custom header' >pg.dump
pg_dump -Fc >>pg.dump
What would anyone hope to achieve by such a manoeuvre, e
(2010/05/27 11:51), Robert Haas wrote:
> Link to previous discussion:
>
> http://archives.postgresql.org/pgsql-hackers/2010-05/msg01195.php
>
> Attached, please find a patch which standardizes the following
> interface for object types that use unqualifed names.
>
> Oid get_whatever_oid(char *na
Tom Lane wrote:
Should we try to make that a bit more consistent, and if so how?
The shenanigans in Makefile.shlib would get a lot simpler if we said
that shlib links always include LDFLAGS *plus* LDFLAGS_SL, but I would
think that that would carry substantial risk of breakage. Surely there
are
On 19 June 2010 14:43, Robert Haas wrote:
> It would be nice if we could make a final push to get these issues
> resolved and another beta out the door before the end of the month...
So should we expect beta3 imminently, or are these issues still outstanding?
Thanks
Thom
--
Sent via pgsql-hac
On Wed, 2010-06-16 at 21:56 -0400, Tom Lane wrote:
> Robert Haas writes:
> > On Wed, Jun 9, 2010 at 8:01 PM, Tom Lane wrote:
> >> Yes, I'll get with it ...
>
> > Any update on this?
>
> Sorry, I've been a bit distracted by other responsibilities (libtiff
> security issues for Red Hat, if you mu
86 matches
Mail list logo
