I wrote:
> Following the discussions in
> http://archives.postgresql.org/pgsql-hackers/2009-09/msg01766.php
> and
> http://archives.postgresql.org/pgsql-hackers/2009-10/msg00025.php ,
> here are patches for
>
> a) a hook in backend/commands/user.c that allows one to add
>password checking func
KaiGai,
* KaiGai Kohei (kai...@ak.jp.nec.com) wrote:
> Please review the new revision, Thanks,
In general, I'm pretty happy with this revision. You still have a
number of places where you have comments about code which does not exist
any more. For example, the comments about the check being rem
On Sun, Oct 11, 2009 at 09:18:20PM -0400, Tom Lane wrote:
> Alvaro Herrera writes:
> > As for builtin functions, I think that's going to be a very hard
> > sell.
>
> Fresh out of the box, there are 2227 entries in pg_proc as of CVS
> HEAD. I don't see making a man page for each one as being a us
Alvaro Herrera writes:
> As for builtin functions, I think that's going to be a very hard sell.
Fresh out of the box, there are 2227 entries in pg_proc as of CVS HEAD.
I don't see making a man page for each one as being a useful activity
...
regards, tom lane
--
Sent vi
David Fetter wrote:
> Folks,
>
> I'd like to see about creating man pages for the following:
>
> - libpq
> - SPI
> - the built-in functions
>
> These being what I've clicked through way too many web links to find
> information about. If there are other things that should have man
> pages, pleas
On Fri, Oct 09, 2009 at 04:35:46PM -0500, Kevin Grittner wrote:
> Peter Eisentraut wrote:
>
> > I think the setting ought be called linestyle unicode (instead of
> > utf8), since the same setting would presumably work in case we ever
> > implement UTF-16 support on the client side.
>
> Yeah, a
Robert Haas writes:
> On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane wrote:
>> It's an entirely trivial code change either way. I'm inclined to think
>> that we should prevent flattening, on the grounds of least astonishment.
> It seems like this is somewhat related to the question of embedding an
David Fetter wrote:
Folks,
I'd like to see about creating man pages for the following:
- libpq
- SPI
- the built-in functions
That would be really helpful and convenient. I've often wanted libpq man pages.
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsq
On Sun, Oct 11, 2009 at 12:35 PM, Tom Lane wrote:
> I'm fooling around with pushing FOR UPDATE locking into a new plan node
> type, and I just noticed a behavior that seems a bit bogus.
> Historically we have dealt with FOR UPDATE in sub-selects by flattening
> the sub-select if we could, because
Folks,
I'd like to see about creating man pages for the following:
- libpq
- SPI
- the built-in functions
These being what I've clicked through way too many web links to find
information about. If there are other things that should have man
pages, please mention same.
How would that be handled
Markus Wanner writes:
> BTW: how do other databases deal with this? Anything of relevance in the
> SQL standards?
SQL99 treats FOR UPDATE as an attribute of DECLARE CURSOR, so there's
no way for it to appear in a sub-select per spec. (In general our
approach to FOR UPDATE is only loosely related
Hi,
Tom Lane wrote:
> It's an entirely trivial code change either way. I'm inclined to think
> that we should prevent flattening, on the grounds of least astonishment.
Yeah, I also tend towards making FOR UPDATE an optimization fence
(that's how I understood the non-flattening approach). While i
I'm fooling around with pushing FOR UPDATE locking into a new plan node
type, and I just noticed a behavior that seems a bit bogus.
Historically we have dealt with FOR UPDATE in sub-selects by flattening
the sub-select if we could, because the alternative was to fail
altogether. For example, consi
13 matches
Mail list logo
