On Sat, Nov 22, 2008 at 6:28 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
> My worry is that there has not been an exhaustive analysis. "Almost
> correct" and "probably correct" is not the same thing as "correct". We
> need to look through all of the changes that occur at the end of
> recovery to be
On 25 nov 2008, at 05.00, Tom Lane <[EMAIL PROTECTED]> wrote:
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
If that's true then this code is presently broken for *every* locale
under Windows, not only Japanese.
Maybe there are a few languages/countires where 2 encodings are
wide
2008/11/25 Tom Lane <[EMAIL PROTECTED]>:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
>> On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
>>> Default parameters are implemented similar to variadic functions - so
>>> no changes on PL part - all changes are on caller part.
>
>> Then I don't
2008/11/25 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>>
>> If you keep this in your mind, please don't be annoyed but the current
>> frame concept is wrong.
>>
>> ...
>>
>> Note that on empno=4 then last_value=4(yours)/3(mine), which means the
>> frame is applied to last_value
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> If that's true then this code is presently broken for *every* locale
>> under Windows, not only Japanese.
> Maybe there are a few languages/countires where 2 encodings are
> widely used.
UTF8 vs Latin-N? In any case I think the prob
Tom Lane wrote:
> Hiroshi Inoue <[EMAIL PROTECTED]> writes:
>> Tom Lane wrote:
>>> I'm not following this either. If the patch is really necessary then it
>>> seems it must be working around a bug in the Windows version of gettext,
>>> ie failure to distinguish CP932 from CP20932. Is that correct
Hiroshi Inoue <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I'm not following this either. If the patch is really necessary then it
>> seems it must be working around a bug in the Windows version of gettext,
>> ie failure to distinguish CP932 from CP20932. Is that correct?
> I'm afraid I don'
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> Hiroshi Inoue wrote:
>>> because Shift_JIS isn't allowed as a server encoding. So
>>> the Japanese Windows native message encoding Shift_JIS never
>>> matches the server encoding EUC_JP and a conversion between
>>> Shitt_jis and EUC_J
"Tao Ma" <[EMAIL PROTECTED]> writes:
> recently, I wrote a really complex SELECT statement which consists of about
> 20 relations using NATURAL JOIN method and every single relation consists 50
> columns. It looks like:
Maybe you should rethink your schema design...
> It seems Postgres cost lot
"Fujii Masao" <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 14, 2008 at 7:15 PM, Fujii Masao <[EMAIL PROTECTED]> wrote:
> > Attached is the latest version of Synch Rep patch. Sorry for my late
> > posting.
> > I fixed some bugs in v1patch and integrated walreceiver into core.
I have some comments abou
On Monday 24 November 2008 09:10:29 Dave Page wrote:
> On Mon, Nov 24, 2008 at 2:01 PM, Magnus Hagander <[EMAIL PROTECTED]>
wrote:
> > Dave Page wrote:
> >> That would defeat the point. Not that I have any great feelings either
> >> way, but fwiw, Microsoft and Oracle both create a sample database
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
>> Default parameters are implemented similar to variadic functions - so
>> no changes on PL part - all changes are on caller part.
> Then I don't understand why you need this special data type
Heikki,
The following test fails with your patch on my system. Could you check
if you can reproduce?
psql (8.4devel)
Type "help" for help.
test=# begin;
BEGIN
test=# create table paul(x int);
CREATE TABLE
test=# insert into paul values(1);
INSERT 0 1
test=# prepare transaction 'persistentTabl
2008/11/24 Peter Eisentraut <[EMAIL PROTECTED]>:
> On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
>> > You mean you want to avoid repeated parsing of expressions in case the
>> > same expression is used as a default value for several parameters? How
>> > common would that be?
>>
>> no -
On Monday 24 November 2008 23:21:15 Pavel Stehule wrote:
> > You mean you want to avoid repeated parsing of expressions in case the
> > same expression is used as a default value for several parameters? How
> > common would that be?
>
> no - I am reading default parameters in call statement parsin
2008/11/24 Peter Eisentraut <[EMAIL PROTECTED]>:
> On Monday 24 November 2008 11:40:31 Pavel Stehule wrote:
>> I would to implement named params - and there expressions, that are
>> used as default params, should not be continual. I don't store params
>> as array of text because I would to eliminat
I wrote:
> Some more information on this:
> https://www.switch.ch/pki/meetings/2007-01/namebased_ssl_virtualhosts.pdf
> slide 5 lists the matching rules for email, HTTP, and LDAP over TLS,
> respectively, which are not all the same. Also note that these methods
> have rules for interpreting fields
Pavel Stehule escribió:
> 2008/11/24 Tom Lane <[EMAIL PROTECTED]>:
> > Say again? The representation Peter is suggesting *is* what is used
> > in rules and views. If you've re-invented that wheel, undo it.
>
> Then I am blind. I store serialised transformed expression, but if
> better solution
On Monday 24 November 2008 16:55:17 Magnus Hagander wrote:
> > Then again, having looked into the libpq source now, is using fnmatch()
> > even appropriate here? The matching rules for https are in RFC 2818:
> > Using fnmatch(), however, will also treat ? and [] special and it will
> > not follow
On Monday 24 November 2008 11:40:31 Pavel Stehule wrote:
> I would to implement named params - and there expressions, that are
> used as default params, should not be continual. I don't store params
> as array of text because I would to eliminate repeated expression's
> parsing. So I use similar ma
On Mon, Nov 24, 2008 at 02:46:45PM -0500, Tom Lane wrote:
> What it boils down to is lack of error checking in psql (not the
> backend). Specifically, we fail to enlarge the output buffer for
> psqlscan.l, which causes appendBinaryPQExpBuffer to silently not insert
> the chunk it's currently being
Sam Mason <[EMAIL PROTECTED]> writes:
> On Mon, Nov 24, 2008 at 10:45:42AM -0500, Tom Lane wrote:
>> Well, I can't reproduce that here. Something strange about your
>> configuration maybe?
> Not that I know of. I've just created a test cluster to make sure and I
> get the same behaviour.
Hmm ..
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Pavan Deolasee escribió:
>> Should we call FreeQueryDesc() even for failed portals in PortalCleanup() ?
>> Or PortalDrop() is a better(right) place to do that ?
> That doesn't work; doing it causes a crash:
I think the fundamental bug here is that you
Gregory Stark <[EMAIL PROTECTED]> writes:
> So if it's possible for the frozenxid in the visibility map to go backwards
> then it's no good, since if that update is lost we might skip a necessary
> vacuum freeze.
Seems like a lost disk write would be enough to make that happen.
Now you might argu
Tom Lane <[EMAIL PROTECTED]> writes:
> Please stick to the convention of including include files in
> alphabetical order.
I didn't realize we had such a convention. Is this for all include files or
only within a directory? Are there exceptions where the order matters or have
we managed to make su
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane escribió:
>> I think the fundamental bug here is that you tried to skip using the
>> ResourceOwner mechanism for snapshot references. That's basically
>> not gonna work.
> Right :-( I'll see how to go about this.
It strikes me that you migh
> Clutter is the problem. The cs_log functions in the example do not
> serve any purpose that is helpful to describe a for loop. They serve
> no real purpose...why not 'raise notice' or just remove them? It
> should be clear to distinguish from real and non-real elements.
+1 for RAISE NOTICE.
Tom Lane escribió:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > Pavan Deolasee escribi�:
> >> Should we call FreeQueryDesc() even for failed portals in PortalCleanup() ?
> >> Or PortalDrop() is a better(right) place to do that ?
>
> > That doesn't work; doing it causes a crash:
>
> I think th
On Monday 24 November 2008 16:07:49 Dave Page wrote:
> That's the point of having a sample database ready to play with. The
> docs needn't have clutter, but the user can try out any of the
> examples without needing to setup anything first. It's a simple
> usability tweak that can help ease the lea
On Mon, Nov 24, 2008 at 1:38 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
> A. Kretschmer wrote:
>
>> Okay, it is an argument. On the other side, it was a question today in
>> the irc-channel (#postgresql) today, someone asked, why his funktion
>> don't work. I think, such examples should not cont
Magnus Hagander <[EMAIL PROTECTED]> writes:
> Hiroshi Inoue wrote:
>> because Shift_JIS isn't allowed as a server encoding. So
>> the Japanese Windows native message encoding Shift_JIS never
>> matches the server encoding EUC_JP and a conversion between
>> Shitt_jis and EUC_JP is necessarily needed
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> However I'm a bit puzzled how you could possibly maintain this frozenxid. As
>> soon as you freeze an xid you'll have to visit all the other pages covered by
>> that visibility map page to see what the new value should be.
>
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> I'm a tad worried about what happens when the values that are
frequently
> occurring in the outer relation are also frequently occurring in the
> inner (which hardly seems an improbable case). Don't you stand a
severe
> risk
Tom Lane wrote:
> KaiGai Kohei <[EMAIL PROTECTED]> writes:
>> However, I think we have a few issues, and it makes unclear whether
>> we can make an agreement in the community.
>> The one is a cost of security hooks. They consume a bit more CPU steps
>> when a security mechanism is enabled. The othe
Gregory Stark wrote:
However I'm a bit puzzled how you could possibly maintain this frozenxid. As
soon as you freeze an xid you'll have to visit all the other pages covered by
that visibility map page to see what the new value should be.
Right, you could only advance it when you scan all the pa
Gregory Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> Please stick to the convention of including include files in
>> alphabetical order.
> I didn't realize we had such a convention. Is this for all include files or
> only within a directory? Are there exceptions wher
On 11/24/08, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Marko Kreen" <[EMAIL PROTECTED]> writes:
> > It was brought to my attention that DISCARD ALL
> > does not release advisory locks:
>
> What is the argument that it should?
DISCARD ALL is supposed to be used by poolers to reset connection
back to
Tom Lane <[EMAIL PROTECTED]> writes:
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
>> I've been thinking that we could add one frozenxid field to each
>> visibility map page, for the oldest xid on the heap pages covered by the
>> visibility map page. That would allow more fine-grained anti-wr
Hi Magnus-san.
Umm, format operand seems to be a wide character sequence.
- Original Message -
From: "Magnus Hagander" <[EMAIL PROTECTED]>
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
*** a/src/backend/utils/adt/pg_locale.c
--- b/src/backend/
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Well, FNM_CASEFOLD is not POSIX, and Autoconf thinks it's a GNU
> extension, which has obviously crept into other systems. So you'd need
> to use AC_FUNC_FNMATCH_GNU, but that also requires you to use the GNU
> replacement implementation. (A bit s
"Marko Kreen" <[EMAIL PROTECTED]> writes:
> It was brought to my attention that DISCARD ALL
> does not release advisory locks:
What is the argument that it should?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
It was brought to my attention that DISCARD ALL
does not release advisory locks:
http://pgfoundry.org/tracker/index.php?func=detail&aid=1010499&group_id=1000258&atid=983
Thus connection managers / poolers need to do that manually.
This obviously means DISCARD ALL needs fixing. Applied
patch
Magnus Hagander wrote:
> Tom Lane wrote:
>> Magnus Hagander <[EMAIL PROTECTED]> writes:
>>> *** a/src/backend/utils/adt/pg_locale.c
>>> --- b/src/backend/utils/adt/pg_locale.c
>>> ***
>>> *** 54,59
>>> --- 54,60
>>> #include "utils/memutils.h"
>>> #include "utils/pg_locale
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Tom Lane wrote:
>>> Magnus Hagander <[EMAIL PROTECTED]> writes:
... The other option is to have
autoconf substitute our own local version of fnmatch when this happens.
How would one go about to do that in autoconf asks the autoconf
Does it work when you're not using C-locale? This looks like the
codepath Tom pointed out was wrong.
//Magnus
Hiroshi Saito wrote:
> Hi Magnus-san.
>
> Um, Though regrettable, it is not in a good state.
> http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/Mugnus-patch.png
>
>
Tom Lane wrote:
> Magnus Hagander <[EMAIL PROTECTED]> writes:
>> *** a/src/backend/utils/adt/pg_locale.c
>> --- b/src/backend/utils/adt/pg_locale.c
>> ***
>> *** 54,59
>> --- 54,60
>> #include "utils/memutils.h"
>> #include "utils/pg_locale.h"
>
>> + #include "mb/pg_wch
Magnus Hagander <[EMAIL PROTECTED]> writes:
> *** a/src/backend/utils/adt/pg_locale.c
> --- b/src/backend/utils/adt/pg_locale.c
> ***
> *** 54,59
> --- 54,60
> #include "utils/memutils.h"
> #include "utils/pg_locale.h"
> + #include "mb/pg_wchar.h"
> #define
Hi Magnus-san.
Um, Though regrettable, it is not in a good state.
http://winpg.jp/~saito/pg_work/LC_MESSAGE_CHECK/LC_TIME_PATCH/Mugnus-patch.png
- Original Message -
From: "Magnus Hagander" <[EMAIL PROTECTED]>
The way I read this patch we do:
1) Get the time in CP_ACP
2) Conver
Peter Eisentraut wrote:
> Magnus Hagander wrote:
>> Anything that needs symlinks will need a set of workarounds on Windows,
>> having us manually do a copy of the files. We already do this in a
>> couple of cases, but relying more on it would make things even more
>> kludgy I think...
>
> Autoconf
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> So it seems like we do indeed want to rejigger autovac's rules a bit
>> to account for the possibility of wanting to apply vacuum to get
>> visibility bits set.
> I'm not too excited about triggering an extra vacuum. As Matthew po
Magnus Hagander wrote:
Anything that needs symlinks will need a set of workarounds on Windows,
having us manually do a copy of the files. We already do this in a
couple of cases, but relying more on it would make things even more
kludgy I think...
Autoconf automatically uses cp if ln doesn't wo
Magnus Hagander wrote:
Tom Lane wrote:
Magnus Hagander <[EMAIL PROTECTED]> writes:
... The other option is to have
autoconf substitute our own local version of fnmatch when this happens.
How would one go about to do that in autoconf asks the autoconf n00b?
I'd try adding a little test program
Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> I've been thinking that we could add one frozenxid field to each
> visibility map page, for the oldest xid on the heap pages covered by the
> visibility map page. That would allow more fine-grained anti-wraparound
> vacuums as well.
This doesn't
On Mon, Nov 24, 2008 at 9:02 AM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Dave Page wrote:
>>> It might also be useful to create such a database at initdb time so
>>> newbies have something interesting to look at right away.
>
>> No, there is no need to cl
am Mon, dem 24.11.2008, um 9:02:37 -0500 mailte Tom Lane folgendes:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
> > Dave Page wrote:
> >> It might also be useful to create such a database at initdb time so
> >> newbies have something interesting to look at right away.
>
> > No, there is no need
On Mon, Nov 24, 2008 at 2:14 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> "Dave Page" <[EMAIL PROTECTED]> writes:
>> On Mon, Nov 24, 2008 at 1:53 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>>> No, there is no need to clutter every installation in the world with such a
>>> database. You could make i
"Dave Page" <[EMAIL PROTECTED]> writes:
> On Mon, Nov 24, 2008 at 1:53 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>> No, there is no need to clutter every installation in the world with such a
>> database. You could make it an addon module, or a pgfoundry project.
> That would defeat the point.
Martin Pihlak wrote:
Here's another revision of the connection manager. This adds:
* reference documentation
* psql, tab-completion, \dw, \dr, \dm commands.
* pg_dump support
Still todo:
* more comprehensive regression tests
* introductory documentation
* dblink support
I hope to finish t
On Mon, Nov 24, 2008 at 2:01 PM, Magnus Hagander <[EMAIL PROTECTED]> wrote:
> Dave Page wrote:
>> That would defeat the point. Not that I have any great feelings either
>> way, but fwiw, Microsoft and Oracle both create a sample database
>> iirc.
>
> Last I checked, MS did it optionally only, no?
Hiroshi Inoue wrote:
> Magnus Hagander wrote:
>> Hiroshi Inoue wrote:
>>> Hi Magnus and all,
>>>
>>> Magnus Hagander wrote:
Log Message:
---
Explicitly bind gettext() to the UTF8 locale when in use.
This is required on Windows due to the special locale
handling for
On Mon, Nov 24, 2008 at 2:02 PM, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew Dunstan <[EMAIL PROTECTED]> writes:
>> Dave Page wrote:
>>> It might also be useful to create such a database at initdb time so
>>> newbies have something interesting to look at right away.
>
>> No, there is no need to cl
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Dave Page wrote:
>> It might also be useful to create such a database at initdb time so
>> newbies have something interesting to look at right away.
> No, there is no need to clutter every installation in the world with
> such a database. You could mak
Dave Page wrote:
> On Mon, Nov 24, 2008 at 1:53 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>>> It might also be useful to create such a database at initdb time so
>>> newbies have something interesting to look at right away.
>>>
>> No, there is no need to clutter every installation in the world
Magnus Hagander wrote:
> Hiroshi Inoue wrote:
>> Hi Magnus and all,
>>
>> Magnus Hagander wrote:
>>> Log Message:
>>> ---
>>> Explicitly bind gettext() to the UTF8 locale when in use.
>>> This is required on Windows due to the special locale
>>> handling for UTF8 that doesn't change the fu
On Mon, Nov 24, 2008 at 1:53 PM, Andrew Dunstan <[EMAIL PROTECTED]> wrote:
>
>> It might also be useful to create such a database at initdb time so
>> newbies have something interesting to look at right away.
>>
>
> No, there is no need to clutter every installation in the world with such a
> datab
am Mon, dem 24.11.2008, um 13:47:54 + mailte Dave Page folgendes:
> On Mon, Nov 24, 2008 at 1:38 PM, Alvaro Herrera
> <[EMAIL PROTECTED]> wrote:
> > A. Kretschmer wrote:
> >
> >> Okay, it is an argument. On the other side, it was a question today in
> >> the irc-channel (#postgresql) today, so
Dave Page wrote:
On Mon, Nov 24, 2008 at 1:38 PM, Alvaro Herrera
<[EMAIL PROTECTED]> wrote:
A. Kretschmer wrote:
Okay, it is an argument. On the other side, it was a question today in
the irc-channel (#postgresql) today, someone asked, why his funktion
don't work. I think, such examp
Pavan Deolasee escribió:
> Following test case gives a warning of snapshot not destroyed at commit
> time.
>
> CREATE TABLE test (a int);
> INSERT INTO test VALUES (1);
> BEGIN;
> DECLARE c CURSOR FOR SELECT * FROM test FOR update;
> SAVEPOINT A;
> FETCH -2 FROM c;
> ROLLBACK TO SAVEPOINT A;
> COM
2008/11/24 Heikki Linnakangas <[EMAIL PROTECTED]>:
> Hitoshi Harada wrote:
>>
>> 2008/11/20 David Rowley <[EMAIL PROTECTED]>:
>>>
>>> I won't be around until Monday evening (Tuesday morning JST). I'll pickup
>>> the review again there. It's really time for me to push on with this
>>> review.
>>> Th
Tom Lane napsal(a):
Zdenek Kotala <[EMAIL PROTECTED]> writes:
Zdenek Kotala napsal(a):
By my opinion there is not reason to retry kill call, because it fails
only in situation if process does not exist or caller does not have
permission to send a signal.
If I think more about it, that code i
A. Kretschmer wrote:
> Okay, it is an argument. On the other side, it was a question today in
> the irc-channel (#postgresql) today, someone asked, why his funktion
> don't work. I think, such examples should not contain such code. It is
> not apparent that this function are not available.
Perhap
2008/11/24 Tom Lane <[EMAIL PROTECTED]>:
> "Pavel Stehule" <[EMAIL PROTECTED]> writes:
>> 2008/11/24 Peter Eisentraut <[EMAIL PROTECTED]>:
>>> Could you explain why you store the default expressions in a new posexpr
>>> type rather than in an array of text (compare pg_attrdef.adbin)?
>
>> I would t
Zdenek Kotala <[EMAIL PROTECTED]> writes:
> Zdenek Kotala napsal(a):
>> By my opinion there is not reason to retry kill call, because it fails
>> only in situation if process does not exist or caller does not have
>> permission to send a signal.
> If I think more about it, that code is here beca
"Pavel Stehule" <[EMAIL PROTECTED]> writes:
> 2008/11/24 Peter Eisentraut <[EMAIL PROTECTED]>:
>> Could you explain why you store the default expressions in a new posexpr
>> type rather than in an array of text (compare pg_attrdef.adbin)?
> I would to implement named params - and there expressions
am Mon, dem 24.11.2008, um 7:24:47 -0500 mailte Merlin Moncure folgendes:
> On Mon, Nov 24, 2008 at 6:02 AM, A. Kretschmer
> <[EMAIL PROTECTED]> wrote:
> > I hope this is the right place to report a bug/issue in the official
> > documentation...
> >
> > In
> > http://www.postgresql.org/docs/curre
Bruce Momjian wrote:
KaiGai Kohei wrote:
What I am saying is for the default compile, SQL-level ACLs should be
possible because, since the ACL field has optional storage, there is no
downside to have it be available by default.
I think it is a possible and desirable desicion from the viewpoint
The way I read this patch we do:
1) Get the time in CP_ACP
2) Convert to UTF16
3) Convert to UTF8
4) If necessary, convert to the charset in the database
We could be more efficient by at least folding 1 and 2 into a single
step, which means getting it in UTF16 from the beginning. How about
attache
I updated the patch set of SE-PostgreSQL (revision 1244).
[1/6]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1244.patch
[2/6]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1244.patch
[3/6]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8.4
Hiroshi Inoue wrote:
> Hi Magnus and all,
>
> Magnus Hagander wrote:
>> Log Message:
>> ---
>> Explicitly bind gettext() to the UTF8 locale when in use.
>> This is required on Windows due to the special locale
>> handling for UTF8 that doesn't change the full environment.
>
> Thanks to t
Peter Eisentraut wrote:
> Tom Lane wrote:
>> I think the reason we've avoided putting such stuff into include/port/
>> is that right now that directory consists exclusively of OS-specific
>> files. Maybe we need another include subdirectory?
>
> I think the idea is rather that you don't need to c
On Mon, Nov 24, 2008 at 6:02 AM, A. Kretschmer
<[EMAIL PROTECTED]> wrote:
> I hope this is the right place to report a bug/issue in the official
> documentation...
>
> In
> http://www.postgresql.org/docs/current/interactive/plpgsql-control-structures.html
> there is an example for a function, cs_re
Tom Lane wrote:
Also, right now we have got
src/include/getaddrinfo.h
src/include/getopt_long.h
which really make me itch now that I am contemplating the possibility
that we try to use libc-supplied code for these functions along with
our own header definitions.
These particular header files
Tom Lane wrote:
I'd suggest making the callers do something like
#ifdef HAVE_FNMATCH
#include
#else
#include "port/pg_fnmatch.h"
#endif
The way Autoconf suggests to organize this is to provide a fake
fnmatch.h (they call it fnmatch_.h) and link it to f
Hitoshi Harada wrote:
2008/11/20 David Rowley <[EMAIL PROTECTED]>:
I won't be around until Monday evening (Tuesday morning JST). I'll pickup
the review again there. It's really time for me to push on with this review.
The patch is getting closer to getting the thumbs up from me. I'm really
hopin
Hello,
thank you, for you review. Grouping Sets is nice feature, but this
patch patch has some issues, and I don't expect commiting into 8.4. I
sent it, because it is interaction with window function's patch and
(maybe) some code should be shared - and this information should be
usefull for other
I hope this is the right place to report a bug/issue in the official
documentation...
In
http://www.postgresql.org/docs/current/interactive/plpgsql-control-structures.html
there is an example for a function, cs_refresh_mviews(), chapter 38.6.4.
Within this function there are a "PERFORM cs_log('Ref
Hi Stehule,
I have looked at the patch and it looks great. Here are my observation
Compilation
1 - Patch applied successfully on CVS-HEAD
2 - No compilation error found
Code
---
1 - Style of code is very close to the existing PG code.
2 - Comments look OK to me.
3 - I haven'
Zdenek Kotala napsal(a):
Tom Lane napsal(a):
What seems to have happened is that the bgwriter didn't get as far as
the first line of BackgroundWriterMain before the client backend tried
to issue a checkpoint request.
This is obviously a pretty minor issue, but it still seems worth fixing.
We c
2008/11/24 Peter Eisentraut <[EMAIL PROTECTED]>:
> Pavel Stehule wrote:
>>
>> I have problem with sending patch, so I am send link
>> http://www.pgsql.cz/patches/defaults.diff.gz
>>
>> Example:
>> postgres=# create function fx(a int, b int default 30, c int default 40)
>
> Could you explain why you
Pavel Stehule wrote:
I have problem with sending patch, so I am send link
http://www.pgsql.cz/patches/defaults.diff.gz
Example:
postgres=# create function fx(a int, b int default 30, c int default 40)
Could you explain why you store the default expressions in a new posexpr
type rather than in
Hi,
recently, I wrote a really complex SELECT statement which consists of about
20 relations using NATURAL JOIN method and every single relation consists 50
columns. It looks like:
PREPARE ugly_stmt AS
SELECT * FROM t1 NATURAL JOIN t2 NATURAL JOIN t3 ... NATURAL JOIN t20 WHERE
id = $1;
All tab
Jim Cox wrote:
A patch s/b attached which adds a "VERBOSE" option to the CLUSTER command as
mentioned in the following TODO item for CLUSTER: "Add VERBOSE option
to report tables as they are processed, like VACUUM VERBOSE".
I have committed this version of your patch, but moving the VERBOSE
op
Tom Lane napsal(a):
What seems to have happened is that the bgwriter didn't get as far as
the first line of BackgroundWriterMain before the client backend tried
to issue a checkpoint request.
This is obviously a pretty minor issue, but it still seems worth fixing.
We could either try to make su
Tom Lane wrote:
* ISTM that the patch is designed on the plan that the PD_ALL_VISIBLE
page header flag *must* be correct, but it's really okay if the backing
map bit *isn't* correct --- in particular we don't trust the map bit
when performing antiwraparound vacuums. This isn't well documented.
94 matches
Mail list logo
