2009/8/9 Alvaro Herrera alvhe...@commandprompt.com:
Jeff Davis escribió:
On Mon, 2009-04-20 at 18:53 +0200, Pavel Stehule wrote:
b) it allows constructors for data types (ANSI SQL)
datatype(typefield1[, typefiedl2[, typefiedl3[, ...]]]) returns type
Can you describe this case in more
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net writes:
I takle it back. It's still there at
http://archives.postgresql.org/pgsql-hackers/2009-08/msg00485.php
posted 3 days ago.
Hmm, I think the archive website must be mangling that somehow.
What I have in the code I'm reviewing is
2009/8/9 Jeff Davis pg...@j-davis.com:
On Sun, 2009-07-26 at 15:29 +0200, Pavel Stehule wrote:
Hello
new patch add new contrib transformations with three modules
anotation, decode and json.
These modules are ported from my older work.
Before applying this patch, please use named-fixed
Michael Paquier michael.paqu...@gmail.com writes:
After making a lot of tests, state file size is not more than 600B.
In some cases, it reached a maximum of size of 712B and I used such
transactions in my tests.
I can only say that that demonstrates you didn't test very many cases.
It is
Tom Lane wrote:
So I'd like to see an actual case made
that there's a strong reason for not requiring FROM/IN in ecpg.
I guess there's only one, compatibility.
Yeah. Are there any other precompilers that actively reject FROM/IN
here? If we're just a bit more strict than they are, it's
Hello
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
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's-eye view, for no real benefit.
Considering that we are worried about someday having to adjust to a
SQL standard in this area, I think we ought to be as conservative as
possible about what we introduce as user-visible features here.
As an example, if they do go with = as the parameter marker,
mixed notation would become a
On Monday 10 August 2009 09:26:33 Tom Lane wrote:
pet...@postgresql.org (Peter Eisentraut) writes:
Ship documentation without intermediate tarballs
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
On Wednesday 05 August 2009 19:59:52 Tom Lane wrote:
Or maybe we are going at this the wrong way? Would it be better to try
harder to support the write-a-plpgsql-function approach?
This would become much simpler if you could just execute plpgsql code instead
of having to define a function
Hi,
This commitfest will soon finish and we can already say, I think, that
the support software is doing a pretty good job helping through
it. Congrats!
Now after some discussion about it on IRC, we have some ideas to improve
the situation some more. Specifically, reviews are touching several
Hello,
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.
LOG: server process (PID
On Monday 10 August 2009 08:39:17 Jaime Casanova wrote:
On Fri, Jul 17, 2009 at 3:19 AM, Peter Eisentrautpete...@gmx.net wrote:
On Thursday 16 July 2009 22:08:25 Kevin Grittner wrote:
On the admin list there was a request for an application name
column in pg_stat_activity.
On Mon, Aug 10, 2009 at 1:56 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Revised patch attached. I'm not convinced this is as good as it can
be, but I've been looking at this patch for so long that I'm starting
to get cross-eyed, and I'd like to Tom at
On Wed, Jul 22, 2009 at 17:05, Magnus Hagandermag...@hagander.net wrote:
Dave has built binaries for 8.3.7 and 8.4.0 for this, available at:
http://developer.pgadmin.org/~dpage/postgres_exe_virtualalloc-8_3.zip
http://developer.pgadmin.org/~dpage/postgres_exe_virtualalloc-8_4.zip
We would
On Mon, Jul 27, 2009 at 09:11, Magnus Hagandermag...@hagander.net wrote:
On Fri, Jul 24, 2009 at 21:33, Dave Pagedp...@pgadmin.org wrote:
On Fri, Jul 24, 2009 at 8:07 PM, Magnus Hagandermag...@hagander.net wrote:
I'm going to apply this for HEAD. I'm considering backpatching as
well, to speed
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
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:
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
On Thu, Aug 6, 2009 at 19:04, Peter Eisentrautpete...@gmx.net 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
On Monday 03 August 2009 17:44:32 Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
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 proposed
2009/8/10 Peter Eisentraut pete...@gmx.net:
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
Magnus Hagander mag...@hagander.net 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
Peter Eisentraut pete...@gmx.net 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
On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
On Mon, Aug 10, 2009 at 3:33 PM, Magnus Hagandermag...@hagander.net wrote:
On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
On Mon, Aug 10, 2009 at 16:45, Dave Pagedp...@pgadmin.org wrote:
On Mon, Aug 10, 2009 at 3:33 PM, Magnus Hagandermag...@hagander.net wrote:
On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
It's been a couple of weeks now, and I've had
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 1:56 AM, Tom Lanet...@sss.pgh.pa.us 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
Brendan Jurd escribió:
2009/8/9 Alvaro Herrera alvhe...@commandprompt.com:
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
On Mon, Aug 10, 2009 at 3:49 PM, Magnus Hagandermag...@hagander.net 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
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us 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
Alvaro Herrera alvhe...@commandprompt.com 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
On Mon, Aug 10, 2009 at 3:58 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote:
8.2 as well, no?
8.2 has a different shmem implementation - the one that emulates sysv
shmem. The patch will need to
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
Alvaro Herrera alvhe...@commandprompt.com 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
Kevin Grittner wrote:
Peter Eisentraut pete...@gmx.net 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
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
Brendan Jurd dire...@gmail.com writes:
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
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
On Mon, Aug 10, 2009 at 4:29 PM, Andrew Dunstanand...@dunslane.net 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
Andrew Dunstan and...@dunslane.net 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
daveg da...@sonic.net 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
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
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 that
Magnus Hagander wrote:
On Thu, Aug 6, 2009 at 19:04, Peter Eisentrautpete...@gmx.net 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
On Mon, Aug 10, 2009 at 10:54 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 1:56 AM, Tom Lanet...@sss.pgh.pa.us wrote:
There are still some open issues:
* I still think we need a written spec for the non-text output formats.
Where
Peter Eisentraut pete...@gmx.net 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,
On Mon, Aug 10, 2009 at 11:36 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 10:54 AM, Tom Lanet...@sss.pgh.pa.us wrote:
FilterExprText(f1 gt; 0)/Text/Expr/Filter
This would leave room to add additional properties beside the text,
and not break existing clients when we do it.
Well, there you
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 direction
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
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
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 at
Christian Thomsen c...@cs.aau.dk 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
On Mon, Aug 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 10:54 AM, Tom Lanet...@sss.pgh.pa.us wrote:
FilterExprText(f1 gt; 0)/Text/Expr/Filter
This would leave room to add additional properties beside the
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Uh, no, I see one container and a property. If we do just
FilterExpr(f1 gt; 0)/Expr/Filter
then where do we put additional information about the expression
when the time
Peter Eisentraut pete...@gmx.net 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Peter Eisentraut pete...@gmx.net 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=#
On Sun, 2009-08-09 at 22:15 -0400, Robert Haas wrote:
On Sun, Aug 9, 2009 at 2:43 PM, Simon Riggssi...@2ndquadrant.com 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
On Mon, Aug 10, 2009 at 5:54 PM, Kevin
Grittnerkevin.gritt...@wicourts.gov 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
2009/8/10 Robert Haas robertmh...@gmail.com:
On Mon, Aug 10, 2009 at 11:36 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Andrew Dunstan and...@dunslane.net 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
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
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 can
Greg Stark gsst...@mit.edu 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.
On Mon, Aug 10, 2009 at 16:58, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net writes:
On Mon, Aug 10, 2009 at 16:10, Tom Lanet...@sss.pgh.pa.us wrote:
8.2 as well, no?
8.2 has a different shmem implementation - the one that emulates sysv
shmem. The patch will need to
On Mon, Aug 10, 2009 at 12:47 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Mon, Aug 10, 2009 at 12:13 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Uh, no, I see one container and a property. If we do just
FilterExpr(f1 gt; 0)/Expr/Filter
then where do
Brendan Jurd dire...@gmail.com 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:
entryliteralto_char(0.000485,
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
Robert Haas robertmh...@gmail.com 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?
Alvaro Herrera alvhe...@commandprompt.com 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
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
Robert Haas robertmh...@gmail.com wrote:
On Sun, Aug 9, 2009 at 12:27 PM, Tom Lanet...@sss.pgh.pa.us 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
2009/8/11 Tom Lane t...@sss.pgh.pa.us:
Working through this now, and I noticed that the example added to the
manual seems to be wrong:
entryliteralto_char(0.000485, '9.99')/literal/entry
entryliteral' 4.850e-04'/literal/entry
With 9.99 as the pattern, I'd expect (and
On Mon, Aug 10, 2009 at 16:10, wader2wad...@jcom.home.ne.jp 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
Brendan Jurd dire...@gmail.com 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
Magnus Hagander mag...@hagander.net 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
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
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 ever
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 there
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
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
2009/8/9 Tom Lane t...@sss.pgh.pa.us:
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
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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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,
2009/8/10 Tom Lane t...@sss.pgh.pa.us:
Brendan Jurd dire...@gmail.com 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
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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
On Mon, Aug 10, 2009 at 10:09 PM, Andrew Dunstan and...@dunslane.netwrote:
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?
Tom Lane t...@sss.pgh.pa.us 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
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 installed
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
Robert Haas robertmh...@gmail.com writes:
On Sun, Jul 26, 2009 at 9:29 AM, Pavel Stehulepavel.steh...@gmail.com 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.
Kevin Grittner kevin.gritt...@wicourts.gov writes:
Tom Lane t...@sss.pgh.pa.us 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
On Mon, Aug 10, 2009 at 1:45 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
On Mon, Aug 10, 2009 at 20:44, Tom Lanet...@sss.pgh.pa.us wrote:
Magnus Hagander mag...@hagander.net 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
Tom Lane t...@sss.pgh.pa.us wrote:
Kevin Grittner kevin.gritt...@wicourts.gov 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)
Tom Lane wrote:
Andrew Dunstan and...@dunslane.net 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
Kevin Grittner kevin.gritt...@wicourts.gov 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
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:
Resending to correct a copy/paste error. Apologies.
Kevin Grittner kevin.gritt...@wicourts.gov 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
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 so
* 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
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 guess
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 offsite
1 - 100 of 112 matches
Mail list logo
