On Dec 8, 2007 3:37 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
If you want to collect all the optimizer items for 8.3 and put them in a
list we can link to them from the web site.
Perhaps we can find a compromise by adding a global item on the
optimizer enhancements with the names of people
OK, I'm thinking that the best way might be to do away with buildenv.bat
altogether and replace the remaining references to it in .bat files with
something like this fragment:
if not exist src\tools\msvc\buildenv.pl goto nobuildenv
perl -e require 'src/tools/msvc/buildenv.pl';
Simon,
Sounds like Josh is asking for a way to find out the things that matter
on an architecture and compare them with the relevant parts of the
pg_control structure. The 32/64 bit thing was probably just his
shorthand for that. Perhaps we should document how to perform a
portability check?
On Sat, 2007-12-08 at 02:46 -0500, Tom Lane wrote:
Gregory Stark [EMAIL PROTECTED] writes:
We could always tighten this up a bit by listing the alignment of a
handful of built-in data types but I suppose there will always be
holes in this area anyways.
In theory yeah, but the note in
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Bruce Momjian wrote:
Stefan Kaltenbrunner wrote:
Let me give you the criteria I use for the release notes. The release
notes try to document all changes visible to the average user in a way
that is understandable to the average user.
hmm I'm
Am Samstag, 8. Dezember 2007 schrieb Josh Berkus:
Pretty much. We're supporting x86 64-bit servers for Solaris now, and
we need SMF to be able to check whether it can safely run x binaries
against y data.
Well, the canonical way to do that is to start the server and see if it
succeeds.
You
Tom Lane wrote:
1. Revert the changes that removed dependencies on PQnoPasswordSupplied.
This is ugly but might be the safest solution for 8.3 --- we can always
revisit the issue later.
3. Invent another libpq function, maybe PQconnectionNeedsPassword,
that does the right thing for the
Bruce Momjian wrote:
Simon Riggs wrote:
On Fri, 2007-12-07 at 16:21 -0500, Bruce Momjian wrote:
If people are concerned about the unfairness, and I understand that,
the
best solution is not to add more items to the release notes to be more
fair, but to remove all names
I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late then. I did just
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, if we want to cram all that stuff in there, how shall we do it?
It seems wrong to put all those lines into one text field, but I'm
not sure I want to add six more text fields to the CSV format
either.
Magnus Hagander wrote:
I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
3. Invent another libpq function, maybe PQconnectionNeedsPassword,
that does the right thing for the password-checking tests.
My vote goes to (3), if the work can be done quickly, or (1) if it
can't.
I don't think it's a big problem
On Sat, 2007-12-08 at 10:09 -0500, Tom Lane wrote:
My vote goes to (3), if the work can be done quickly, or (1) if it
can't.
Ditto.
I don't think it's a big problem to do, as long as we are agreed on
the behavior we want. In particular, consider:
1. If libpq obtains a password
Magnus Hagander wrote:
I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't make more
changes before was because I thought it was too late
Guillaume Smet wrote:
On Dec 8, 2007 3:37 AM, Bruce Momjian [EMAIL PROTECTED] wrote:
If you want to collect all the optimizer items for 8.3 and put them in a
list we can link to them from the web site.
Perhaps we can find a compromise by adding a global item on the
optimizer enhancements
Alvaro Herrera wrote:
Simon's the guy who (rightfully, IMHO) smacked me for forgetting to
credit him on a commit message. Credit is important to some people.
Let's not get in the business of annoying the people who gives their
work for free. For some, credit is the second sole reason for
I am actually a little worried that companies who sponsor developers
might some day want their company name on the release note item. I am
glad we have not had to make that decision yet. This actually
O.k. I will bite :)
highlights a danger of having giving credit be a more major part of
Bruce Momjian wrote:
I don't think people are going to volunteer to remove just their name
but they might agree to remove them all. As a contributor I personally
would have no problem with that.
I would.
I am actually a little worried that companies who sponsor developers
might some day
On Sat, 2007-12-08 at 11:34 -0500, Andrew Dunstan wrote:
Magnus Hagander wrote:
I agree with getting rid of the remaining .bat files, or at least making
them one line wrappers for perl scripts, but I think it's too late in
the cycle for that now. As I explained, the reason I didn't
Alvaro Herrera wrote:
Yeah. In my opinion, we're not really looking for 100% fairness. I
think credit is important, so if Stefan Kaltenbrunner did some psql
autocomplete work and it's not attributed, let's add a note to that
effect. There is no point in saying exactly how many lines he
Joshua D. Drake wrote:
Alvaro Herrera wrote:
Yeah. In my opinion, we're not really looking for 100% fairness. I
think credit is important, so if Stefan Kaltenbrunner did some psql
autocomplete work and it's not attributed, let's add a note to that
effect. There is no point in saying
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
One issue here is that CONTEXT is potentially multiple lines. I'm not
sure that there is much we can do about that, especially not at the last
minute. If we had some time to rewrite internal APIs it might be fun to
think about
Mark Cave-Ayland [EMAIL PROTECTED] writes:
I'd say that you definitely don't want a user password prompt if libpq's
password is wrong, since I can see this would break a lot of scripts
that weren't launched directly from the shell
Agreed, we don't want the behavior to suddenly turn interactive
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
One issue here is that CONTEXT is potentially multiple lines. I'm not
sure that there is much we can do about that, especially not at the last
minute. If we had some time to rewrite internal APIs it might be
While going through the contrib documentation, I notice that both
oid2name and pgbench allow specifying a password on the command line,
ie
-P password
This is known to be horribly bad security practice (because the password
is exposed to everyone else on the machine), and we don't allow
On Saturday 08 December 2007 16:01, Alvaro Herrera wrote:
Alternatively we could use the contributors list (currently developers
list) as the definitive source and just provide a link.
I think that's a bad idea, because it doesn't keep historical
information. Furthermore it seems inactive
Tom Lane wrote:
While going through the contrib documentation, I notice that both
oid2name and pgbench allow specifying a password on the command line,
ie
-P password
This is known to be horribly bad security practice (because the password
is exposed to everyone else on the machine),
27 matches
Mail list logo
