> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org [mailto:pgsql-hackers-
> ow...@postgresql.org] On Behalf Of Tom Lane
> Sent: Monday, July 13, 2009 7:43 PM
> To: Andrew Dunstan
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Upgrading our minimum required flex ver
Jaime Casanova wrote:
> i can find value for FORCE QUOTE * but what's
> the use case for FORCE NOT NULL?
NULLs are not quoted (to be ,, ) because empty strings are written as "".
It comes from original implementation and not from my patch.
I think we don't need to change the behavior.
Regards,
2009/5/7 Dickson S. Guedes :
> Em Qui, 2009-05-07 às 10:11 +0300, Peter Eisentraut escreveu:
>> On Thursday 07 May 2009 05:23:41 Dickson S. Guedes wrote:
>> > This is a WIP patch (for the TODO item in the subject) that I'm putting
>> > in the Commit Fest queue for 8.5.
>>
>> How about you just put
On Mon, May 11, 2009 at 11:49 PM, Itagaki
Takahiro wrote:
> Hi,
>
> The attached is a WIP patch add a support of '*' for FORCE QUOTE
> and FORCE NOT NULL options. I'd like to submit it for the next
> commit fest (8.5). Comments welcome.
>
this patch applies almost cleanly except for a hunk in gram
Robert Haas wrote:
>> If so, I can postpone some of permission checks outside of the
>> pg_xxx_aclcheck(). However, SELinux's security model often
>> requires different criteria to make its decision.
>> (Please note that I never say either of them is better or worse.)
>> Thus, we will need to add s
2009/7/14 KaiGai Kohei :
> Robert Haas wrote:
>> 2009/7/13 KaiGai Kohei :
>>> The sepgsql/avc.c provides a facility to cache access control decisions
>>> in userspace, and enables to reduce time of kernel invocations.
>>> However, its size is the largest one in the SE-PgSQL patch.
>>
>> I think tha
Robert Haas wrote:
> 2009/7/13 KaiGai Kohei :
>> The sepgsql/avc.c provides a facility to cache access control decisions
>> in userspace, and enables to reduce time of kernel invocations.
>> However, its size is the largest one in the SE-PgSQL patch.
>
> I think that caching access control decisio
On Mon, Jul 13, 2009 at 5:38 PM, Mischa
Sandberg wrote:
> Does PG have an intermediate execution node to sort/batch index entries (heap
> tuple ptrs) by heap page prior to lookup? Something mssql does ...
>
it sounds a lot like a bitmap index scan
--
Atentamente,
Jaime Casanova
Soporte y capac
Pavel Stehule escribió:
> 2009/7/13 Alvaro Herrera :
> > Pavel Stehule escribió:
> >> Hello
> >>
> >> I did some similar (but Oracle like) in orafce - so it can help. I
> >> thing, so this should be very useful, but result set isn't best
> >> format. Usually you would to print to log and you have t
Tom Lane wrote:
Andrew Dunstan writes:
Well, it looks like there's a reason GnuWin32 hasn't advanced beyond
2.5.4a - after that the flex developers proceeded to make flex use a
filter chain methodology that requires the use of fork(). Making it run
on Windows without the support of Msy
2009/7/13 KaiGai Kohei :
> The sepgsql/avc.c provides a facility to cache access control decisions
> in userspace, and enables to reduce time of kernel invocations.
> However, its size is the largest one in the SE-PgSQL patch.
I think that caching access control decisions in userspace is a good
th
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > Jamie Fox wrote:
> > >
> > > > > I can also see that the pg_largeobject table is different, in the
> > > > > pg_restore
> > > > > version the Rows (estimated) is 316286 and Rows (counted) is
Andrew Dunstan writes:
> Well, it looks like there's a reason GnuWin32 hasn't advanced beyond
> 2.5.4a - after that the flex developers proceeded to make flex use a
> filter chain methodology that requires the use of fork(). Making it run
> on Windows without the support of Msys or Cygwin wou
Tom Lane wrote:
> Bruce Momjian writes:
> > Tilmann Singer wrote:
> >> However, all of the sequences were at the initial values and not
> >> bumped up to the last used value as I would have expected. The first
> >> nextval call on any sequence in the migrated 8.4 database always
> >> returned 1.
>
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Alvaro Herrera wrote:
> > > Bruce Momjian wrote:
> > > > Jamie Fox wrote:
> > >
> > > > > I can also see that the pg_largeobject table is different, in the
> > > > > pg_restore
> > > > > version the Rows (estimated) is 316286 and Rows (counted) is
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
> > > Jamie Fox wrote:
> >
> > > > I can also see that the pg_largeobject table is different, in the
> > > > pg_restore
> > > > version the Rows (estimated) is 316286 and Rows (counted) is the same,
> > > > in
> > > > the pg_m
Does PG have an intermediate execution node to sort/batch index entries (heap
tuple ptrs) by heap page prior to lookup? Something mssql does ...
> -Original Message-
> From: pgsql-hackers-ow...@postgresql.org
> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Bruce Momjian
> Sent:
Andrew Dunstan wrote:
OK, the fly in this ointment turns out to be MSVC. The latest flex
from GnuWin32 is 2.5.4a, and building 2.5.35 for Windows is turning
out to be quite a pain. Luckily, MinGW has a pre-built modified 2.5.33
available, and I have installed this (also needed msys-regex),
Robert,
The sepgsql/avc.c provides a facility to cache access control decisions
in userspace, and enables to reduce time of kernel invocations.
However, its size is the largest one in the SE-PgSQL patch.
[kai...@saba gram]$ wc -l src/backend/security/sepgsql/avc.c
829 src/backend/security/sepgs
Bruce Momjian writes:
> Tilmann Singer wrote:
>> However, all of the sequences were at the initial values and not
>> bumped up to the last used value as I would have expected. The first
>> nextval call on any sequence in the migrated 8.4 database always
>> returned 1.
> Wow, that is also surprisi
Alvaro Herrera wrote:
> Tom Lane escribi?:
> > Robert Haas writes:
> > > What would be really nice is to provide an easy and PORTABLE way for
> > > patch submitters to run pgindent themselves.
> >
> > AFAIK it's just BSD indent plus some private patches of Bruce's, so
> > there's no good reason w
Tom Lane escribió:
> Robert Haas writes:
> > What would be really nice is to provide an easy and PORTABLE way for
> > patch submitters to run pgindent themselves.
>
> AFAIK it's just BSD indent plus some private patches of Bruce's, so
> there's no good reason we couldn't distribute pgindent in so
Tom Lane wrote:
> Robert Haas writes:
> > What would be really nice is to provide an easy and PORTABLE way for
> > patch submitters to run pgindent themselves.
>
> AFAIK it's just BSD indent plus some private patches of Bruce's, so
> there's no good reason we couldn't distribute pgindent in sourc
On Monday 13 July 2009 23:37:10 Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > BTW I discovered a couple of years ago that if you set the DSSSL stuff
> > to build only the index and not output the HTML, the first pass is
> > *very* fast. It required patching some lispy file however, so I'm not
Robert Haas writes:
> What would be really nice is to provide an easy and PORTABLE way for
> patch submitters to run pgindent themselves.
AFAIK it's just BSD indent plus some private patches of Bruce's, so
there's no good reason we couldn't distribute pgindent in source form.
There just hasn't be
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> > Jamie Fox wrote:
>
> > > I can also see that the pg_largeobject table is different, in the
> > > pg_restore
> > > version the Rows (estimated) is 316286 and Rows (counted) is the same, in
> > > the pg_migrator version the Rows (counted) is only 180
Bruce Momjian wrote:
> Jamie Fox wrote:
> > I can also see that the pg_largeobject table is different, in the pg_restore
> > version the Rows (estimated) is 316286 and Rows (counted) is the same, in
> > the pg_migrator version the Rows (counted) is only 180507.
> Wow, I didn't test large objects
Tilmann Singer wrote:
> I tried the latest pg_migrator
> (http://pgfoundry.org/frs/download.php/2291/pg_migrator-8.4.tgz) to
> migrate a database from an 8.3.7 to an 8.4.0 cluster. It finished with
> a success message, and the schema and all tables seem to have been
> migrated correctly.
>
> Howev
Forwarded to hackers.
---
Jamie Fox wrote:
> Hi -
> This is probably more helpful - the pg_largeobject table only changed after
> vacuumlo, not before. When comparing pre- and post- pg_migrator databases
> (no vacuum or vac
Jamie Fox wrote:
> Hi -
> After what seemed to be a normal successful pg_migrator migration from 8.3.7
> to 8.4.0, in either link or copy mode, vacuumlo fails on both our production
> and qa databases:
>
> Jul 1 11:17:03 db2 postgres[9321]: [14-1] LOG: duration: 175.563 ms
> statement: DELETE F
Greg Stark wrote:
> On Mon, Jul 13, 2009 at 7:04 PM, Kevin
> Grittner wrote:
>> As far as our production queries go, based on our experience with
>> several other products against this schema, this is the area where
>> the biggest performance gains remain to be realized.
>
>
> There's a logical
On Mon, Jul 13, 2009 at 7:04 PM, Kevin
Grittner wrote:
> As far as our production queries go, based on our experience with
> several other products against this schema, this is the area where the
> biggest performance gains remain to be realized.
There's a logical fallacy implicit in this stateme
Robert Haas escribió:
> What would be really nice is to provide an easy and PORTABLE way for
> patch submitters to run pgindent themselves. Then you can pgindent on
> every commit, and if you break somebody's patch series, it's there own
> fault for not pgindenting it correctly before they submit
On Friday 05 December 2008 11:13:37 Kurt Harriman wrote:
> Fortunately, there are not many instances which are likely
> to be encountered by our C++ guests, and these can easily
> be changed. In memnodes.h, parsenodes.h, and primnodes.h,
> this patch changes the following field
On Friday 05 December 2008 11:18:46 Kurt Harriman wrote:
> This patch adds C++ support to the PostgreSQL build system.
Unless you can provide a significant specific use case, I think this patch is
rejected. Building part of PostgreSQL sometimes with C++ would just add too
much uncertainty
On Mon, Jul 13, 2009 at 3:57 PM, Tom Lane wrote:
> "Kevin Grittner" writes:
>> Peter Eisentraut wrote:
>>> It will mostly look like a beta release
>
>> No pgindent run I assume?
>
> No, that would tend to break pending patches.
>
> There's been some talk of pgindenting just new code added by patc
On Friday 05 December 2008 11:16:37 Kurt Harriman wrote:
> Just a few additional header files are mentioned in the PostgreSQL
> Reference Manual for add-on developers to use: fmgr.h, funcapi.h,
> and spi.h. This patch adds bookends within those three files for
> the benefit of begin
Folks,
As previously announced, CommitFest 2009-07 will begin on July 15th.
For the sake of clarity, I'd like to propose that the deadline for
patch submission be fixed at:
Wed Jul 15 00:00:00 UTC 2009
...which is just under 26.5 hours from now. Barring objections, at
that time, I (or someone)
On Mon, Jul 13, 2009 at 4:00 PM, A.M. wrote:
>
> How would I go about generating a meaningful backtrace for a plpgsql
> function that calls a plperl function? One would also expect a C function
> which calls a plpgsql function to appear, too, no? Shouldn't there be a
> unified backtrace subsystem?
On Jul 13, 2009, at 4:51 PM, decibel wrote:
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
Alvaro Herrera writes:
Tom Lane wrote:
The performance and error recovery implications are unfavorable.
Just how badly do you need this, and for what?
Mainly for debugging. The situation is such tha
On Mon, Jul 13, 2009 at 3:48 PM, decibel wrote:
> On Jul 13, 2009, at 1:06 PM, Simon Riggs wrote:
>>
>> Not just because of this but I wonder if we might benefit from an
>> optimizer setting specifically aimed at the foolishnesses of
>> automatically generated SQL.
>
>
> +1. And it's not just ORMs
On Jul 13, 2009, at 2:33 PM, Tom Lane wrote:
Alvaro Herrera writes:
Tom Lane wrote:
The performance and error recovery implications are unfavorable.
Just how badly do you need this, and for what?
Mainly for debugging. The situation is such that there is a lot of
functions and very high loa
On Jul 13, 2009, at 1:06 PM, Simon Riggs wrote:
Not just because of this but I wonder if we might benefit from an
optimizer setting specifically aimed at the foolishnesses of
automatically generated SQL.
+1. And it's not just ORMs that do stupid things, I've seen crap like
this come out of u
2009/7/14 Robert Haas :
>
> +1 for redirecting the whole site. I don't think the extra CPU load
> of SSL is going to bother anyone for the amount of traffic we're
> likely to have on that site. Simplicity is good.
>
+1 for SSL on all pages from me also.
Cheers,
BJ
--
Sent via pgsql-hackers ma
On Mon, 2009-07-13 at 10:16 +0300, Heikki Linnakangas wrote:
> Implementing index-only scans requires a few changes:
I would like to see a clear exposition of the use cases and an an
analysis of the costs and benefits of doing this. It sounds cool, but I
want to know it is cool before we spend t
Alvaro Herrera wrote:
> BTW I discovered a couple of years ago that if you set the DSSSL stuff
> to build only the index and not output the HTML, the first pass is
> *very* fast. It required patching some lispy file however, so I'm not
> sure if we can usefully take advantage of that. I can find
Tom Lane wrote:
> Peter Eisentraut writes:
> > I think I have finally figured out a way to do this correctly now.
>
> Yay. The existing method completely sucks --- I find that it *never*
> does one run on a rebuild, but at least two and sometimes three.
> I don't know whether it's feasible to im
Tom Lane wrote:
> Peter Eisentraut writes:
> > I think I have finally figured out a way to do this correctly now.
>
> Yay. The existing method completely sucks --- I find that it *never*
> does one run on a rebuild, but at least two and sometimes three.
> I don't know whether it's feasible to im
Peter Eisentraut writes:
> I think I have finally figured out a way to do this correctly now.
Yay. The existing method completely sucks --- I find that it *never*
does one run on a rebuild, but at least two and sometimes three.
I don't know whether it's feasible to implement "rebuild only if the
On Monday 13 July 2009 22:47:40 Alvaro Herrera wrote:
> Peter Eisentraut wrote:
> > == Release preparation ==
> > src/tools/RELEASE_CHANGES applies
>
> No library soname bumps, right?
The soname, which is name + major version number, is only bumped when the ABI
changes.
Perhaps you refer to the
On Monday 13 July 2009 22:49:21 Bruce Momjian wrote:
> Kevin Grittner wrote:
> > Peter Eisentraut wrote:
> > > It will mostly look like a beta release
> >
> > No pgindent run I assume?
>
> I don't think so.
No, certainly not.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
"Kevin Grittner" writes:
> Peter Eisentraut wrote:
>> It will mostly look like a beta release
> No pgindent run I assume?
No, that would tend to break pending patches.
There's been some talk of pgindenting just new code added by patches
at the time they're committed. We don't seem to have th
Alvaro Herrera wrote:
> Peter Eisentraut wrote:
>
> > == Release preparation ==
> > src/tools/RELEASE_CHANGES applies
>
> No library soname bumps, right?
No, I doubt it.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If you
Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > It will mostly look like a beta release
>
> No pgindent run I assume?
I don't think so.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, C
Peter Eisentraut wrote:
> * Release notes [Note: We'll have to work out exactly how to do this one as
> we
> go.]
I am not planning to assist with this item for alpha releases.
--
Bruce Momjian http://momjian.us
EnterpriseDB http://enterprisedb.com
+
Peter Eisentraut wrote:
> == Release preparation ==
> src/tools/RELEASE_CHANGES applies
No library soname bumps, right?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers
Peter Eisentraut wrote:
> It will mostly look like a beta release
No pgindent run I assume?
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Alvaro Herrera wrote:
> This is a preliminary request for comments on obtaining a function call
> stack. I've been trying to dodge the issue by exporting elog.c internal
> state (errcontext), but that turns out to be unfeasible and it's such a
> horrid kludge anyway.
>
> So, the idea is to have a
2009/7/13 Alvaro Herrera :
> Pavel Stehule escribió:
>> Hello
>>
>> I did some similar (but Oracle like) in orafce - so it can help. I
>> thing, so this should be very useful, but result set isn't best
>> format. Usually you would to print to log and you have to iterate via
>> set. So maybe better
Alvaro Herrera writes:
> Tom Lane wrote:
>> The performance and error recovery implications are unfavorable.
>> Just how badly do you need this, and for what?
> Mainly for debugging. The situation is such that there is a lot of
> functions and very high load. The functions have embedded "debug
For those of you who weren't involved in the Ottawa developer meeting, I think
we should start by explaining that beginning with the 8.5 development cycle,
we are planning to make regular alpha releases, to make early testing easier
for more users. This will happen at the end of every commit fe
On Jul 13, 2009, at 2:02 PM, Tom Lane wrote:
Alvaro Herrera writes:
So, the idea is to have a stack maintained by the function
manager; each
called function enters an element in it containing the interesting
information about the function. We'd have another function that
would
return this
Pavel Stehule escribió:
> Hello
>
> I did some similar (but Oracle like) in orafce - so it can help. I
> thing, so this should be very useful, but result set isn't best
> format. Usually you would to print to log and you have to iterate via
> set. So maybe better format could be some structured te
Tom Lane wrote:
> Alvaro Herrera writes:
> > So, the idea is to have a stack maintained by the function manager; each
> > called function enters an element in it containing the interesting
> > information about the function. We'd have another function that would
> > return this stack as a result
Hello
I did some similar (but Oracle like) in orafce - so it can help. I
thing, so this should be very useful, but result set isn't best
format. Usually you would to print to log and you have to iterate via
set. So maybe better format could be some structured text.
regards
Pavel Stehule
2009/7/1
On Mon, Jul 13, 2009 at 01:22:30PM +0900, Itagaki Takahiro wrote:
> Sam Mason wrote:
> > As others have said, handling encryption client side would seem to offer
> > many more benefits (transparently within libpq offering easy adoption).
>
> Libpq is not the only driver. Do we need to develop tra
Tom Lane wrote:
> Writing a join for a single-table query? Why, in heavens name?
> (Or have you mercifully blotted the details from your memory?)
Actually, I had only the vaguest recollection of why, but I found an
email where I was explaining the problem to Sybase. Basically, it
boiled down
Alvaro Herrera writes:
> So, the idea is to have a stack maintained by the function manager; each
> called function enters an element in it containing the interesting
> information about the function. We'd have another function that would
> return this stack as a result set. (With this arrangeme
Hi,
This is a preliminary request for comments on obtaining a function call
stack. I've been trying to dodge the issue by exporting elog.c internal
state (errcontext), but that turns out to be unfeasible and it's such a
horrid kludge anyway.
So, the idea is to have a stack maintained by the func
On Mon, Jul 13, 2009 at 1:33 PM, Tom Lane wrote:
> Simon Riggs writes:
>> In some cases, we have SQL being submitted that has superfluous
>> self-joins. An example would be
>
>> select count(*)
>> from foo1 a, foo1 b
>> where a.c1 = b.c1 /* PK join */
>> and a.c2 = 5
>> and b.c2 = 10;
>
>> You may
On Mon, 2009-07-13 at 13:33 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > In some cases, we have SQL being submitted that has superfluous
> > self-joins. An example would be
>
> > select count(*)
> > from foo1 a, foo1 b
> > where a.c1 = b.c1 /* PK join */
> > and a.c2 = 5
> > and b.c2 = 10
Heikki Linnakangas wrote:
> Implementing index-only scans requires a few changes:
I'm happy to see this work! Now that the EXISTS predicates have been
optimized to consider semi-join and anti-join techniques, I believe
that these index issues (evaluating quals before heap access and
skipping he
"Kevin Grittner" writes:
> Simon Riggs wrote:
>> select count(*)
>> from foo1 a, foo1 b
>> where a.c1 = b.c1 /* PK join */
> We had to do something like that to get acceptable performance from
> Sybase ASE.
Writing a join for a single-table query? Why, in heavens name?
(Or have you merciful
Simon Riggs writes:
> In some cases, we have SQL being submitted that has superfluous
> self-joins. An example would be
> select count(*)
> from foo1 a, foo1 b
> where a.c1 = b.c1 /* PK join */
> and a.c2 = 5
> and b.c2 = 10;
> You may well ask who would be stupid enough to write SQL like tha
Simon Riggs wrote:
> select count(*)
> from foo1 a, foo1 b
> where a.c1 = b.c1 /* PK join */
> You may well ask who would be stupid enough to write SQL like that.
> The answer is of course that it is automatically generated by an
> ORM.
We had to do something like that to get acceptable pe
Andrew Dunstan wrote:
Tom Lane wrote:
I see that a good-sized
fraction of the buildfarm is still on flex 2.5.4 and will therefore go
red when this goes in. Should I hold off a bit longer, or is committing
the best way to get their attention?
Probably the latter. I will update my vario
In some cases, we have SQL being submitted that has superfluous
self-joins. An example would be
select count(*)
from foo1 a, foo1 b
where a.c1 = b.c1 /* PK join */
and a.c2 = 5
and b.c2 = 10;
We can recognise that and are the same table because they are
joined on the PK. PK is never NULL, s
Daniel Schuchardt wrote:
> Is that is the wished behavoir?
>
> template1=# SELECT 1='1';
> ?column?
> --
> t
> (1 row)
Yes. See also this:
alvherre=# select 1 = '1'::text;
ERROR: operator does not exist: integer = text
LÍNEA 1: select 1 = '1'::text;
^
SUGERENCIA: No o
Tom Lane wrote:
> Now this disappears into the noise as soon as you include parse
> analysis (let alone planning and execution)
No need to go for silly options to avoid a performance issue at that
level. Time wasted dealing with subsequent silliness would almost
certainly have a higher "lost
Tom Lane wrote:
> One thought here is that an AM call isn't really free, and doing two of
> them instead of one mightn't be such a good idea. I would suggest
> either having a separate AM entry point to get both bits of data
> ("amgettupledata"?) or adding an optional parameter to amgettuple.
I'm
Heikki Linnakangas writes:
> Tom Lane wrote:
>> What are you going to do for index types that don't store the original
>> data (e.g. hash)?
> They will obviously not be able to regurgitate index tuples. I have not
> yet decided how that's going to be signaled.
Well, I think that's a pretty criti
Is that is the wished behavoir?
template1=# SELECT 1='1';
?column?
--
t
(1 row)
*template1=# SELECT 1 LIKE '1';
ERROR: operator does not exist: integer ~~ unknown at character 10*
HINT: No operator matches the given name and argument type(s). You
might need to add explicit type casts.
Tom Lane wrote:
> Heikki Linnakangas writes:
>> At the moment, amgettuple only returns pointers to heap tuples. There is
>> no way to return data from the index tuples. That needs to be changed to
>> support index-only scans.
>
> What are you going to do for index types that don't store the origi
Michael Meskes írta:
> On Sat, Jul 04, 2009 at 05:09:04PM +0200, Boszormenyi Zoltan wrote:
>
>> OK, let me retry. This version treats "string" as a non-reserved word,
>> and also discovers whether the PGC contains this construct below,
>> as in ecpg/tests/preproc/type.pgc:
>>
>> exec sql type st
Heikki Linnakangas writes:
> At the moment, amgettuple only returns pointers to heap tuples. There is
> no way to return data from the index tuples. That needs to be changed to
> support index-only scans.
What are you going to do for index types that don't store the original
data (e.g. hash)?
On Mon, Jul 13, 2009 at 8:47 AM, Peter Eisentraut wrote:
> On Friday 10 July 2009 19:35:56 Stefan Kaltenbrunner wrote:
>> https support is now available on that jail (maybe we should simply
>> always redirect to the https url on all pages).
>
> Yeah, at least the login page should be redirected to
Michael Meskes írta:
> On Sat, Jul 04, 2009 at 03:39:14PM +0200, Boszormenyi Zoltan wrote:
>
>> The attached patch is built upon our previous patch supporting
>> dynamic cursor and SQLDA.
>>
>
> Please don't do this unless the new patch relies on some changes made in the
> older one.
>
> M
On Saturday 11 July 2009 17:37:03 andrzej barszcz wrote:
> Well, best to write this way:
>
> Goal : query splitted to base elements
> Result : xml response from server
> Client : select pg_reparse_query();
> Target: 8.4 version
>
> How : modification of ruleutiles.c
> Not done : UNION etc.
> Not do
Josh Berkus wrote:
> after the final minor release date, there is no guarantee
INAL, but that *seems* like it might open the community or its members
to lawsuits based on an implied guarantee up to the final minor
release date.
-Kevin
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Heikki Linnakangas wrote:
> Even if we don't solve the visibility
> map problem, just allowing the executor to evaluate quals that are not
> directly indexable using data from the index, would be useful. For
> example, "SELECT * FROM foo WHERE textcol LIKE '%bar%', and you have a
> b-tree index on
On Friday 10 July 2009 19:35:56 Stefan Kaltenbrunner wrote:
> https support is now available on that jail (maybe we should simply
> always redirect to the https url on all pages).
Yeah, at least the login page should be redirected to https. Right now, you
have to detect the SSL support by guessi
On Mon, Jul 13, 2009 at 8:19 AM, Heikki
Linnakangas wrote:
>
> I propose that we split index_getnext into two steps: fetching the next
> match from the index (index_next()), and fetching the corresponding heap
> tuple (index_fetch()).
A pretty trivial concern, but it seems confusing that the funct
At the moment, amgettuple only returns pointers to heap tuples. There is
no way to return data from the index tuples. That needs to be changed to
support index-only scans.
I propose that we split index_getnext into two steps: fetching the next
match from the index (index_next()), and fetching the
Implementing index-only scans requires a few changes:
1. indexam API changes
There's currently no way to return data from an index scan. You only get
TID pointers to heap tuples.
2. Make visibility map crash-safe
After crash, the visibility map can currently be left in state where it
has some b
Tom Lane wrote:
>> I'd suggest that we publish an official policy, with the following dates
>> for "EOL":
>
> But on the whole I think we should NOT have such a policy, at all.
[...]
> If someone wants a guaranteed EOL date, they ought to be contracting
> with a commercial support company and pay
95 matches
Mail list logo
