2009/8/11 Pavel Stehule :
> It's nice. I am playing with it, and now I found some potential issue.
> The parser is maybe too tolerant:
>
> postgres=# select to_char(3.14323,'9.9(a');
> to_char
> --
> 3.1e+00
> (1 row)
>
I guess we *could* add code to throw an error where the 9's
On Tuesday, August 11, 2009, Heikki Linnakangas
wrote:
>
>
> 2009/8/11 Robert Haas
>
> We should probably have a separate discussion about what the least
> committable unit would be for this patch. I wonder if it might be
> sufficient to provide a facility for streaming WAL, plus a standalone
>
2009/8/11 Robert Haas
> We should probably have a separate discussion about what the least
> committable unit would be for this patch. I wonder if it might be
> sufficient to provide a facility for streaming WAL, plus a standalone
> tool for receving it and storing it to a file. This might be d
On Fri, Aug 7, 2009 at 10:44 AM, Jaime
Casanova wrote:
> On Thu, Aug 6, 2009 at 10:46 PM, Robert Haas wrote:
>>
>> I am not sure whether this has been formally reviewed by anyone yet;
>> do we think it's "Ready for Committer"?
>>
>
> i was trying to make some review of this but besides that it comp
On Mon, Aug 10, 2009 at 9:51 PM, Bruce Momjian wrote:
> What is the status of hot standby and synchronous replication? Is there
> a design specification? Who are the lead developers? Who is assisting?
> What open item do we have for each feature? Where is the most recent
> patch? Can we increm
2009/8/10 Tom Lane :
> Robert Haas writes:
>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>> wrote:
>>> new patch add new contrib "transformations" with three modules
>>> anotation, decode and json.
>
>> These are pretty good examples, but the whole thing still feels a bit
>> grotty to me. Th
2009/8/10 Tom Lane :
> Robert Haas writes:
>> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule
>> wrote:
>>> new patch add new contrib "transformations" with three modules
>>> anotation, decode and json.
>
>> These are pretty good examples, but the whole thing still feels a bit
>> grotty to me. Th
On Mon, Aug 10, 2009 at 7:57 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 10, 2009 at 1:45 PM, Tom Lane wrote:
>>> The way we have this set up, there's a distinction between properties
>>> and groups, which AFAICS we have to have in order to have directly
>>> comparable structures in X
What is the status of hot standby and synchronous replication? Is there
a design specification? Who are the lead developers? Who is assisting?
What open item do we have for each feature? Where is the most recent
patch? Can we incrementally start applying patches for these features?
Would some
Robert Haas writes:
> On Mon, Aug 10, 2009 at 1:45 PM, Tom Lane wrote:
>> The way we have this set up, there's a distinction between properties
>> and groups, which AFAICS we have to have in order to have directly
>> comparable structures in XML and JSON. Didn't you design this
>> yourself?
> Ye
Herodotos Herodotou escreveu:
> This patch extends the query optimizer to consider joins between child tables
> when hierarchies are joined together.
>
> Short description: when the optimizer considers join paths between two tables
> with child tables, it only creates join paths over two append
Simon Riggs wrote:
>
> On Mon, 2009-08-10 at 10:20 -0700, Josh Berkus wrote:
>
> > Simon: you have people offering to help with the patch. Offering to
> > help *right now*. Might I suggest that you establish a GIT branch for
> > Hot Standby so that more people can collaborate? Working on it u
Robert Haas writes:
> Me neither, but every place that we know pgindent will touch is like a
> little land-mine waiting to go off under somebody's patch. It seems
> like we ought to try to keep the tree as pgindent-clean as possible
> when we make changes, so that there are as few of those land-m
On Mon, Aug 10, 2009 at 11:15:51PM +0100, Simon Riggs wrote:
> On Mon, 2009-08-10 at 10:20 -0700, Josh Berkus wrote:
>
> > Simon: you have people offering to help with the patch. Offering
> > to help *right now*. Might I suggest that you establish a GIT
> > branch for Hot Standby so that more p
On Mon, 2009-08-10 at 10:20 -0700, Josh Berkus wrote:
> Simon: you have people offering to help with the patch. Offering to
> help *right now*. Might I suggest that you establish a GIT branch for
> Hot Standby so that more people can collaborate? Working on it until
> you get it "perfect" off
Robert Haas escribió:
> But if there are patches against that code, then they've been broken
> now and they will break again when the pgindent run is done. If the
> indentation is fixed at commit-time (or before someone goes to the
> trouble of fixing them), then they get broken only once. I gue
* Josh Berkus (j...@agliodbs.com) wrote:
> I'm not agreeing, though, that we don't need a GRANT ALL/ALTER DEFAULT.
> We still need that for the simplest cases so that novice-level users
> will use *some* access control. But it would mean that we wouldn't need
> GRANT ALL/ALTER DEFAULT to support
> Something like
> DO $$ begin ...; end $$;
>
> gives 90% of the usability with 10% of the trouble.
I'd be a big fan of this. Especially if we could at an \e for it in
psql. \ec?
I'm not agreeing, though, that we don't need a GRANT ALL/ALTER DEFAULT.
We still need that for the simplest cases
Resending to correct a copy/paste error. Apologies.
"Kevin Grittner" wrote:
> Yeah -- my argument would be that the = operator in NULLIF should be
> treated the same as if the function-like abbreviation were rewritten
> to the full CASE predicate. It doesn't surprise me that that is
> taken
Heikki Linnakangas wrote:
Something like
DO $$ begin ...; end $$;
gives 90% of the usability with 10% of the trouble.
Yes, I think that's the consensus.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www
"Kevin Grittner" wrote:
> Yeah -- my argument would be that the = operator in NULLIF should be
> treated the same as if the function-like abbreviation were rewritten
> to the full CASE predicate. It doesn't surprise me that that is
> taken as text, given that they are both unadorned character
Tom Lane wrote:
> Andrew Dunstan writes:
>> But to make it really nice you'd have to move away from pl programs as
>> strings. That would be a lot more work, and you really wouldn't want to
>> make it work with more than one PL for the sake of everyone's sanity.
You mean something like:
postgr
Tom Lane wrote:
> "Kevin Grittner" writes:
[Correcting typo below.]
>> Well, in the SQL specification, COALESCE is defined as an
>> abbreviation of the CASE predicate, so to the extent that anyone
>> pays attention to the spec, this:
>> COALESCE(a, b)
>> should be treated identically to:
>>
On Mon, Aug 10, 2009 at 20:44, Tom Lane wrote:
> Magnus Hagander writes:
>> If I just move those two lines into the #ifndef WIN32 block just
>> around it, it compiles and doesn't crash on running-with-no-arguments.
>> I haven't tried to actually use it though - can someone confirm if
>> this will
On Mon, Aug 10, 2009 at 1:45 PM, Tom Lane wrote:
> Robert Haas writes:
>> I may be thick as a post here and say "oh, I'm a moron" when you
>> explain this to me, but I still don't understand why that would
>> require the XML notation to interpose an intermediate node. Why can't
>> "filter" node i
"Kevin Grittner" writes:
> Tom Lane wrote:
>> In the specific case of COALESCE, we could theoretically do that,
>> since the only computation it needs is "IS NULL" which is
>> datatype-independent.
> Well, in the SQL specification, COALESCE is defined as an abbreviation
> of the CASE predicate,
Robert Haas writes:
> On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehule wrote:
>> new patch add new contrib "transformations" with three modules
>> anotation, decode and json.
> These are pretty good examples, but the whole thing still feels a bit
> grotty to me. The set of syntax transformations t
I wrote:
> COALESCE(a, b)
>
> should be treated identically to:
>
> CASE WHEN a IS NULL THEN a ELSE b END
In case it's not obvious that the above has a typo, I meant:
CASE WHEN a IS NOT NULL THEN a ELSE b END
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgres
Peter Eisentraut wrote:
> Log Message:
> ---
> Ship documentation without intermediate tarballs
>
> Documentation files in HTML and man formats are now prepared for
> distribution using the distprep make target, like everything else. They
> are placed in doc/src/sgml/html and manX and ins
Tom Lane wrote:
> In the specific case of COALESCE, we could theoretically do that,
> since the only computation it needs is "IS NULL" which is
> datatype-independent.
Well, in the SQL specification, COALESCE is defined as an abbreviation
of the CASE predicate, so to the extent that anyone pay
On Mon, Aug 10, 2009 at 10:09 PM, Andrew Dunstan wrote:
> I wonder if this is another case of the lack of perl library initialisation
>> bug we have seen before. Can you try with this patch to the postgres 8.3
>> sources? <
>> http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/pl/plperl/plperl.c.d
"Kevin Grittner" writes:
> Tom Lane wrote:
>> "Kevin Grittner" writes:
>>> Still, it rates pretty high on my astonishment scale that a
>>> COALESCE of two untyped NULLs (or for that matter, any two values
>>> of unknown type) returns a text value.
>>
>> What would you have it do instead, throw
2009/8/10 Tom Lane :
> Brendan Jurd writes:
>> Here's version 7.
>
> Applied with a couple of corrections: the numeric case wasn't dealing
> with NaNs in the same way as the float cases, and the int8 case was
> converting to float8 which would lose precision. I made it go through
> numeric instea
Tom Lane wrote:
> "Kevin Grittner" writes:
>> Still, it rates pretty high on my astonishment scale that a
>> COALESCE of two untyped NULLs (or for that matter, any two values
>> of unknown type) returns a text value.
>
> What would you have it do instead, throw an error?
Return a value of unk
Alexey Klyukin wrote:
Hi,
I was recently running both pl/perl and pl/perlu functions in a single
session, coming across the error message about failure to allocate a
second Perl interpreter on my platform. I'm running PostgreSQL 8.3.7
built from the sources on Mac OS X 10.5 with perl instal
2009/8/9 Tom Lane :
> Oh, another thing: the present restriction that all function parameters
> after the first one with a default must also have defaults is based on
> limitations of positional call notation. Does it make sense to relax
> that restriction once we allow named call notation, and if
2009/8/9 Tom Lane :
> I've now read most of this patch, and I think there are some things that
> need rework, and perhaps debate about what we want.
>
> 1. As I already mentioned, I think the mixed-notation business is a bad
> idea. It's unintuitive, it's not especially useful, and it substantiall
Peter Eisentraut wrote:
> On Monday 10 August 2009 18:43:26 Bruce Momjian wrote:
> > Are you sure you don't want the results in doc/src/man1 and
> > doc/src/html? Or even doc/man1 and doc/html?
>
> I am in fact not sure, but people are used to working on doc/src/sgml, so
> keeping the main action
On Monday 10 August 2009 18:43:26 Bruce Momjian wrote:
> Are you sure you don't want the results in doc/src/man1 and
> doc/src/html? Or even doc/man1 and doc/html?
I am in fact not sure, but people are used to working on doc/src/sgml, so
keeping the main action there seemed reasonable. If we eve
Hi,
I was recently running both pl/perl and pl/perlu functions in a single
session, coming across the error message about failure to allocate a
second Perl interpreter on my platform. I'm running PostgreSQL 8.3.7
built from the sources on Mac OS X 10.5 with perl installed from
macports (m
Magnus Hagander writes:
> If I just move those two lines into the #ifndef WIN32 block just
> around it, it compiles and doesn't crash on running-with-no-arguments.
> I haven't tried to actually use it though - can someone confirm if
> this will actually make pg_standby not work properly?
It would
"Kevin Grittner" writes:
> Still, it rates pretty high on my astonishment scale that a
> COALESCE of two untyped NULLs (or for that matter, any two values of
> unknown type) returns a text value.
What would you have it do instead, throw an error?
The current behavior is a lot less astonishing fo
Brendan Jurd writes:
> Here's version 7.
Applied with a couple of corrections: the numeric case wasn't dealing
with NaNs in the same way as the float cases, and the int8 case was
converting to float8 which would lose precision. I made it go through
numeric instead, which is pretty expensive but
On Mon, Aug 10, 2009 at 16:10, wader2 wrote:
> Bruce Momjian wrote:
>>
>> I can't reproduce a crash here on BSD:
>>
>> $ pg_standby
>> pg_standby: not enough command-line arguments
>>
>> Can you show us the command and the crash text?
>
> I guess this occurs on only windows (Japanese
2009/8/11 Tom Lane :
> Working through this now, and I noticed that the example added to the
> manual seems to be wrong:
>
> to_char(0.000485, '9.99')
> ' 4.850e-04'
>
> With 9.99 as the pattern, I'd expect (and indeed I get) 4.85e-04
> not 4.850e-04. This is correct behavior, no
Robert Haas wrote:
> On Sun, Aug 9, 2009 at 12:27 PM, Tom Lane wrote:
>> Now that I've started to read this patch ... exactly what is the
>> argument for allowing a "mixed" notation (some of the parameters
>> named and some not)? ISTM that just serves to complicate both the
>> patch and the user'
Tom Lane escribió:
> BTW, this patch adds more NUM_cache_remove() calls. I'm planning
> to commit it that way, unless you're just about to commit your PG_TRY
> change? I agree with doing that, but figured it should be a separate
> commit.
No, go ahead, I will commit that separately.
--
Alvaro
Alvaro Herrera writes:
> Tom Lane escribió:
>> Doesn't seem quite right. Should we throw error if the number of 9's
>> before the decimal point isn't 1?
> No, see
> http://archives.postgresql.org/message-id/4a68fae4.50...@timbira.com
Ah, nothing like being bug-compatible with a bad implementati
Robert Haas writes:
> I may be thick as a post here and say "oh, I'm a moron" when you
> explain this to me, but I still don't understand why that would
> require the XML notation to interpose an intermediate node. Why can't
> "filter" node itself can be the labelled container?
Filter isn't a no
Tom Lane escribió:
> Also, I'm wondering what should happen with
>
> regression=# select to_char(0.000485, '99.99');
> to_char
> ---
> 4.85e-04
> (1 row)
>
> Doesn't seem quite right. Should we throw error if the number of 9's
> before the decimal point isn't 1?
No, see
http:
Brendan Jurd writes:
> Thanks Tom. I have removed the V1 stuff as you suggest, and placed
> the declaration in numeric.h.
> Here's version 7.
Working through this now, and I noticed that the example added to the
manual seems to be wrong:
to_char(0.000485, '9.99')
' 4.850e-0
On Mon, Aug 10, 2009 at 12:47 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 10, 2009 at 12:13 PM, Tom Lane wrote:
>>> Uh, no, I see one container and a property. If we do just
>>>
>>> (f1 > 0)
>>>
>>> then where do we put additional information about the expression
>>> when the
On Mon, Aug 10, 2009 at 16:58, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 10, 2009 at 16:10, Tom Lane wrote:
>>> 8.2 as well, no?
>
>> 8.2 has a different shmem implementation - the one that emulates sysv
>> shmem. The patch will need to be changed around for that, and I
>> haven't l
Greg Stark wrote:
> Given that pg_typeof() is a relatively new and pg-specific piece of
> machinery how did this bite you on on your conversion to Postgres
> some years ago?
It wasn't the use of pg_typeof which caused us problems, but the types
the example demonstrated. Primarily that bit us
On Mon, 2009-08-10 at 10:20 -0700, Josh Berkus wrote:
> All,
>
> Can we stop arguing about a patch everyone wants?
>
> Simon: you have people offering to help with the patch. Offering to
> help *right now*. Might I suggest that you establish a GIT branch for
> Hot Standby so that more people c
All,
Can we stop arguing about a patch everyone wants?
Simon: you have people offering to help with the patch. Offering to
help *right now*. Might I suggest that you establish a GIT branch for
Hot Standby so that more people can collaborate? Working on it until
you get it "perfect" offsite do
On Mon, Aug 10, 2009 at 5:54 PM, Kevin
Grittner wrote:
>
> We now have workarounds in place for everywhere this bit us on
> conversion to PostgreSQL, but it was actually one of the greater
> sources of pain in that process
Given that pg_typeof() is a relatively new and pg-specific piece of
mac
2009/8/10 Robert Haas :
> On Mon, Aug 10, 2009 at 11:36 AM, Tom Lane wrote:
>> Andrew Dunstan writes:
>>> One fairly simple way would use a new SQL verb (say, DO) like this:
>>
>>> DO $$ something in plfoo $$ LANGUAGE plfoo;
>>
>> Yeah, this has been suggested before. I can't see anything very wr
On Sun, 2009-08-09 at 22:15 -0400, Robert Haas wrote:
> On Sun, Aug 9, 2009 at 2:43 PM, Simon Riggs wrote:
> > I've said very clearly that I am working on this and it's fairly
> > laughable to suggest that anybody thought I wasn't. What more should I
> > do to prove something is "active" if you won
"Kevin Grittner" writes:
> Peter Eisentraut wrote:
>> reimplement a bunch of core functionality like COALESCE
> If such an effort could reduce the astonishment factor for the
> following, it would justify a certain amount of effort, in my view:
> test=# select pg_typeof('x');
> pg_typeof
>
Peter Eisentraut wrote:
> reimplement a bunch of core functionality like COALESCE
If such an effort could reduce the astonishment factor for the
following, it would justify a certain amount of effort, in my view:
test=# select pg_typeof('x');
pg_typeof
---
unknown
(1 row)
test=#
Robert Haas writes:
> On Mon, Aug 10, 2009 at 12:13 PM, Tom Lane wrote:
>> Uh, no, I see one container and a property. If we do just
>>
>>(f1 > 0)
>>
>> then where do we put additional information about the expression
>> when the time comes?
> I would assume you would just write:
> (f
On Mon, Aug 10, 2009 at 12:13 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 10, 2009 at 10:54 AM, Tom Lane wrote:
>>> (f1 > 0)
>>>
>>> This would leave room to add additional properties beside the text,
>>> and not break existing clients when we do it.
>
>> Well, there you seem t
Christian Thomsen writes:
> I have created a set-returning C function and a view that selects all
> the returned rows. When I use SELECT * FROM theview, the returned rows
> look fine. But if I use, e.g., SELECT count(*) FROM theview or SELECT
> sum(a) FROM theview, I get a segmentation fault.
> L
Robert Haas escribió:
> What the hell? I have every version of that patch I've ever submitted
> in ~/patch/explain-as-submitted, and that extra semicolon is not there
> in any of them. Furthermore, when I open up the attachment from my
> sent mail, the semicolon isn't there either. Yet I see it
2009/8/11 Tom Lane :
> If it's not meant to be in pg_proc, I wouldn't bother with using the V1
> call protocol for it. "extern char *numeric_out_sci(Numeric x)" would
> be sufficient, and less notation on both caller and callee sides.
>
Thanks Tom. I have removed the V1 stuff as you suggest, and
Boszormenyi Zoltan írta:
> OK, here's the WIP patch for the unified core/ecpg grammar,
> with opt_from_in. But I am still getting the 2 shift/reduce
> conflicts exactly for the FORWARD and BACKWARD rules
> that I was getting originally. Can you look at this patch and
> point me to the right directi
Robert Haas writes:
> On Mon, Aug 10, 2009 at 10:54 AM, Tom Lane wrote:
>>(f1 > 0)
>>
>> This would leave room to add additional properties beside the text,
>> and not break existing clients when we do it.
> Well, there you seem to be adding TWO containers, which is probably
> overkill.
On Mon, Aug 10, 2009 at 11:36 AM, Tom Lane wrote:
> Andrew Dunstan writes:
>> One fairly simple way would use a new SQL verb (say, DO) like this:
>
>> DO $$ something in plfoo $$ LANGUAGE plfoo;
>
> Yeah, this has been suggested before. I can't see anything very wrong
> with it.
>
>> We could eve
Peter Eisentraut writes:
> On Monday 10 August 2009 09:26:33 Tom Lane wrote:
>> After this patch, "make clean" in the doc/src/sgml directory no longer
>> does anything useful. Even "make distclean" fails to remove all the
>> cruft left behind by a build. This needs to be rethought a bit,
>> else
On Mon, Aug 10, 2009 at 10:54 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Mon, Aug 10, 2009 at 1:56 AM, Tom Lane wrote:
>>> There are still some open issues:
>>>
>>> * I still think we need a written spec for the non-text output formats.
>
>> Where would we put this in the documentation? Seem
Magnus Hagander wrote:
> On Thu, Aug 6, 2009 at 19:04, Peter Eisentraut wrote:
> > On Thursday 06 August 2009 17:33:40 Tom Lane wrote:
> >> I don't think there'd be much logical difficulty in having an output
> >> field (ie, CSV column or log_line_prefix escape) that represents a
> >> classificatio
Peter Eisentraut wrote:
> So the next step to documentation bliss is to get rid of the man.tar.gz and
> postgres.tar.gz tarballs that are shipped inside the tarball. These are
> historical artifacts from the era when building the documentation for release
> required manual interference, and tha
> I took at a first crack at coding up an implementation of
> relation_is_distinct_for() tonight.
I am not sure if this will help or not, but on the 8.4 code base we
implemented two functions:
- getCandidateKeys() - would recursively traverse a tree from a given
node to the leaf nodes and determi
daveg wrote:
> When I was at Sybase, changes to the on disk structure were required
> to provide code to do the migration. Nonetheless, at release time,
> the migrate process was almost always discovered to be broken,
> sometimes even before it was shipped to customers.
As a long-time user of
Andrew Dunstan writes:
> One fairly simple way would use a new SQL verb (say, DO) like this:
> DO $$ something in plfoo $$ LANGUAGE plfoo;
Yeah, this has been suggested before. I can't see anything very wrong
with it.
> We could even default the langauge to plpgsql, for which you would then
>
On Mon, Aug 10, 2009 at 4:29 PM, Andrew Dunstan wrote:
>
> I hope you're not suggesting we drop Mingw/MSys as a build platform, even if
> you personally don't want to build with it. I would have found it much
> harder to do parallel restore for Windows (which works quite differently
> from Unix, an
Brendan Jurd writes:
> 2009/8/11 Tom Lane :
>> If we expose it at fmgr level it should definitely not return cstring.
>> However, I wasn't foreseeing doing that --- does the submitted patch
>> expose it?
> Sorry, I'm a little hazy on the terminology here. If by "expose it at
> fmgr level" you me
Dave Page wrote:
If it's at all hard to do, I could see deprecating 8.2 for Windows
instead.
I could most definitely agree with that on a personal level - no more
Mingw/msys builds to maintain :-)
Alas, it's probably not practical to drop it without inconveniencing a
great many Windows
Kevin Grittner wrote:
Peter Eisentraut wrote:
This would become much simpler if you could just execute plpgsql
code instead of having to define a function around it.
I have often wished for that feature.
You're not Robinson Crusoe.
It could be done in several ways.
One fa
2009/8/11 Tom Lane :
> Alvaro Herrera writes:
>> I wondered if it should just return char *. If we want to have this
>> functionality as its own fmgr-blessed function, shouldn't it return
>> text instead of cstring?
>
> If we expose it at fmgr level it should definitely not return cstring.
> Howe
On Mon, Aug 10, 2009 at 3:58 PM, Tom Lane wrote:
> Magnus Hagander writes:
>> On Mon, Aug 10, 2009 at 16:10, Tom Lane wrote:
>>> 8.2 as well, no?
>
>> 8.2 has a different shmem implementation - the one that emulates sysv
>> shmem. The patch will need to be changed around for that, and I
>> haven't
Alvaro Herrera writes:
>> Got you thinking about what? I'd welcome any comments you have.
> I wondered if it should just return char *. If we want to have this
> functionality as its own fmgr-blessed function, shouldn't it return
> text instead of cstring?
If we expose it at fmgr level it shou
Magnus Hagander writes:
> On Mon, Aug 10, 2009 at 16:10, Tom Lane wrote:
>> 8.2 as well, no?
> 8.2 has a different shmem implementation - the one that emulates sysv
> shmem. The patch will need to be changed around for that, and I
> haven't looked at that. It may be worthwhile to do that, but it'
On Mon, Aug 10, 2009 at 3:49 PM, Magnus Hagander wrote:
>> Has anyone reported the problem on 8.2?
>
> Yes. I've seen reports of it all the way back to 8.0. It does seem to
> have increased in frequently with Win2003 and Win2008 as the server
> platforms, which means the newer versions have had a h
Brendan Jurd escribió:
> 2009/8/9 Alvaro Herrera :
> > I noticed an ugly pattern in NUMDesc_prepare calling a cleanup function
> > before every ereport(ERROR). I think it's cleaner to replace that with
> > a PG_TRY block; see attached.
>
> Looks nice -- although doesn't have anything to do with
Robert Haas writes:
> On Mon, Aug 10, 2009 at 1:56 AM, Tom Lane wrote:
>> There are still some open issues:
>>
>> * I still think we need a written spec for the non-text output formats.
> Where would we put this in the documentation? Seems like it might
> need a new section/chapter somewhere.
On Mon, Aug 10, 2009 at 16:45, Dave Page wrote:
> On Mon, Aug 10, 2009 at 3:33 PM, Magnus Hagander wrote:
>> On Mon, Aug 10, 2009 at 16:10, Tom Lane wrote:
>>> Magnus Hagander writes:
It's been a couple of weeks now, and I've had a number of reports both
on-list, on-blog and in private,
On Mon, Aug 10, 2009 at 3:33 PM, Magnus Hagander wrote:
> On Mon, Aug 10, 2009 at 16:10, Tom Lane wrote:
>> Magnus Hagander writes:
>>> It's been a couple of weeks now, and I've had a number of reports both
>>> on-list, on-blog and in private, from people using this. I have not
>>> yet had a singl
On Mon, Aug 10, 2009 at 16:10, Tom Lane wrote:
> Magnus Hagander writes:
>> It's been a couple of weeks now, and I've had a number of reports both
>> on-list, on-blog and in private, from people using this. I have not
>> yet had a single report of a problem caused by this patch (not
>> counting th
Peter Eisentraut wrote:
> This would become much simpler if you could just execute plpgsql
> code instead of having to define a function around it.
I have often wished for that feature.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your su
Magnus Hagander writes:
> It's been a couple of weeks now, and I've had a number of reports both
> on-list, on-blog and in private, from people using this. I have not
> yet had a single report of a problem caused by this patch (not
> counting the case where there was a version mismatch - can't fau
2009/8/10 Peter Eisentraut :
> On Sunday 09 August 2009 05:21:48 Jeff Davis wrote:
>> * If the hook can implement XML, should we refactor the XML support (and
>> COALESCE, etc.) to use the hook for the sake of consistency? If the hook
>> is not good enough for those features, that might indicate a
On Sunday 09 August 2009 05:21:48 Jeff Davis wrote:
> * If the hook can implement XML, should we refactor the XML support (and
> COALESCE, etc.) to use the hook for the sake of consistency? If the hook
> is not good enough for those features, that might indicate a problem.
Well, for 8.4, I propose
On Monday 03 August 2009 17:44:32 Tom Lane wrote:
> Andrew Dunstan writes:
> > Does it need a version number change? Maybe just a tag (no branch) is
> > all that is required.
>
> I think that we do want the alpha releases to identify themselves as
> such. And we want a marker in CVS as to what st
On Thu, Aug 6, 2009 at 19:04, Peter Eisentraut wrote:
> On Thursday 06 August 2009 17:33:40 Tom Lane wrote:
>> I don't think there'd be much logical difficulty in having an output
>> field (ie, CSV column or log_line_prefix escape) that represents a
>> classification of the PID, say as "postmaster,
Andres Freund wrote:
On Monday 10 August 2009 14:39:22 Andrew Dunstan wrote:
Andres Freund wrote:
I produced/mailed a relaxng version for a a bit older version and I plan
to refresh and document it once the format seems suitably stable. I am
not sure it is yet. If yes, this should not
On Monday 10 August 2009 14:39:22 Andrew Dunstan wrote:
> Andres Freund wrote:
> > I produced/mailed a relaxng version for a a bit older version and I plan
> > to refresh and document it once the format seems suitably stable. I am
> > not sure it is yet. If yes, this should not take that long...
>
Andres Freund wrote:
I produced/mailed a relaxng version for a a bit older version and I plan to
refresh and document it once the format seems suitably stable. I am not sure
it is yet. If yes, this should not take that long...
(Relaxng because you easily can convert it into most other XML sche
On Mon, Jul 27, 2009 at 09:11, Magnus Hagander wrote:
> On Fri, Jul 24, 2009 at 21:33, Dave Page wrote:
>> On Fri, Jul 24, 2009 at 8:07 PM, Magnus Hagander wrote:
>>
>>> I'm going to apply this for HEAD. I'm considering backpatching as
>>> well, to speed up all build machines. Comments on that?
>>
1 - 100 of 109 matches
Mail list logo
