Ok, that adds some clarity. Have base types (int32, etc) had the same
oid values for a significant number of versions of PgSQL? What I am
getting at is this: can I hard code oid values into an access layer for
PgSQL? I see that the Java driver uses select statements back into the
db to determin
"Reggie Burnett" <[EMAIL PROTECTED]> writes:
> I have started experimenting with an access layer for pgsql and have a
> question. I had someone on this list tell me that the oid values that
> come back from the server are tag identifiers for that row/column
> combination and are not type indicator
I have started experimenting with an access layer for pgsql and have a
question. I had someone on this list tell me that the oid values that
come back from the server are tag identifiers for that row/column
combination and are not type indicators. Yet, when I create multiple
tables/columns each h
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> That's a good kluge, but still a kluge: it doesn't completely guarantee
>> that no one else connects while pg_upgrade is trying to do its thing.
> I was thinking about using GUC:
> #max_connections = 32
> #superuser_reserv
Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > On Sat, 2003-01-04 at 02:17, Tom Lane wrote:
> >> There isn't any simple way to lock *everyone* out of the DB and still
> >> allow pg_upgrade to connect via the postmaster, and even if there were,
> >> the DBA could too easily forget
Tom Lane wrote:
> Any other arguments out there?
Per-release tags make it easier to see quickly if some code has
changed in -current or not. As the CVS tree is available via anoymous
CVS (I think?), CVSup, and via the web so there are many potential
users who are not active developers and who p
Justin Clift <[EMAIL PROTECTED]> writes:
> It's fixed now. :-)
Better, thanks.
Minor suggestion: could we get ALT text for all the flags? Right now
it's there for USA, UK, Italy, but not the rest ...
regards, tom lane
---(end of broadcast)--
Hi Tom,
Sorry about that. Was a combo of two simple problems.
It's fixed now. :-)
Regards and best wishes,
Justin Clift
Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
the portal itself is not mirrored, butif you go to, for instance
UsersLounge or Downloads, it then gives
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> This would require a nontrivial amount of work (notably, we'd have to
>> be able to get pg_dump to run against a standalone backend) but I don't
>> think I'd trust pg_upgrade as a production-grade tool until its
>> invocation method
Tom Lane writes:
> This would require a nontrivial amount of work (notably, we'd have to
> be able to get pg_dump to run against a standalone backend) but I don't
> think I'd trust pg_upgrade as a production-grade tool until its
> invocation method looks like the above.
I would recommend requirin
Bear Giles writes:
> The server policy is easy to handle - it would probably go into a
> new text configuration file pg_ssl.conf.
postgresql.conf should serve you fine.
> The client policy is much harder to handle, since the details need
> to be hidden in the libpg library. I know how to handle
On Sun, 5 Jan 2003, Justin Clift wrote:
> www.postgresql.org/doc -> www.ca.postgresql.org/users-lounge/
If we can avoid it, let's ... if I recall correctly, we originally set
that up in order to get around some issues we had with originally moving
over to the new site way way back ...
-
Marc G. Fournier wrote:
On Sat, 4 Jan 2003, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
the portal itself is not mirrored, butif you go to, for instance
UsersLounge or Downloads, it then gives you the option of which mirror to
go to ...
Ah. But if I do either, I see
War
On Sat, 4 Jan 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > the portal itself is not mirrored, butif you go to, for instance
> > UsersLounge or Downloads, it then gives you the option of which mirror to
> > go to ...
>
> Ah. But if I do either, I see
>
> Warning: pg_e
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> the portal itself is not mirrored, butif you go to, for instance
> UsersLounge or Downloads, it then gives you the option of which mirror to
> go to ...
Ah. But if I do either, I see
Warning: pg_exec(): supplied argument is not a valid PostgreSQL
On Sat, 4 Jan 2003, Tom Lane wrote:
> "Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> > I'm just announcing here, since I'd like to see some ppl testing this out
> > and let us know if there are any problems ... DNS is going to take a
> > little while to propogate, so the old site may still come
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I never considered tag'ng for minor releases as having any importance,
> since the tarball's themselves provide the 'tag' ... branches give us the
> ability to back-patch, but tag's don't provide us anything ... do they?
Well, a tag makes it feasibl
--On Saturday, January 04, 2003 21:04:32 -0400 "Marc G. Fournier"
<[EMAIL PROTECTED]> wrote:
On Sat, 4 Jan 2003, Tom Lane wrote:
Dan Langille <[EMAIL PROTECTED]> writes:
> On Sat, 4 Jan 2003, Peter Eisentraut wrote:
>> There is a long tradition of systematically failing to tag releases in
>>
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> I'm just announcing here, since I'd like to see some ppl testing this out
> and let us know if there are any problems ... DNS is going to take a
> little while to propogate, so the old site may still come up in the
> interium ... another reason not t
On Sat, 4 Jan 2003, Tom Lane wrote:
> Dan Langille <[EMAIL PROTECTED]> writes:
> > On Sat, 4 Jan 2003, Peter Eisentraut wrote:
> >> There is a long tradition of systematically failing to tag releases in
> >> this project. Don't expect it to improve.
>
> > It was I who suggested that a release tea
Let me know how it goes, and what the project is ... that way we can move
the current CVS over so that we don't lose the extensive logging history
...
On Fri, 3 Jan 2003, D'Arcy J.M. Cain wrote:
> On Friday 03 January 2003 15:24, Tom Lane wrote:
> > "D'Arcy J.M. Cain" <[EMAIL PROTECTED]> write
I'm just announcing here, since I'd like to see some ppl testing this out
and let us know if there are any problems ... DNS is going to take a
little while to propogate, so the old site may still come up in the
interium ... another reason not to announce it right away :)
Tom Lane writes:
> > As long as we're spending time on this, why not just write our own version
> > of getopt_long()?
>
> Seems like a fine idea to me ... who's volunteering?
Doing it now...
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)-
msg resent because I incorrectly copied/pasted some addresses. Sorry.
On 4 Jan 2003 at 11:08, Tom Lane wrote:
> Dan Langille <[EMAIL PROTECTED]> writes:
> > On Sat, 4 Jan 2003, Peter Eisentraut wrote:
> >> There is a long tradition of systematically failing to tag releases
> >> in this project.
msg resent because I incorrectly copied/pasted some addresses.
Sorry.
On 4 Jan 2003 at 11:08, Tom Lane wrote:
> Dan Langille <[EMAIL PROTECTED]> writes:
> > On Sat, 4 Jan 2003, Peter Eisentraut wrote:
> >> There is a long tradition of systematically failing to tag releases
> >> in this project.
On Sat, 2003-01-04 at 09:53, Tom Lane wrote:
> Oliver Elphick <[EMAIL PROTECTED]> writes:
> > On Sat, 2003-01-04 at 02:17, Tom Lane wrote:
> >> There isn't any simple way to lock *everyone* out of the DB and still
> >> allow pg_upgrade to connect via the postmaster, and even if there were,
> >> the
On Sat, 2003-01-04 at 06:59, Kaare Rasmussen wrote:
> > Umm. No. User or system level threads, the statement is true. If a
> > thread kills over, the process goes with it. Furthermore, on Win32
>
> Hm. This is a database system. If one of the backend processes dies
> unexpectedly, I'm not sur
On Sat, 2003-01-04 at 04:27, Peter Eisentraut wrote:
> Greg Copeland writes:
>
> > Just a reminder, there still doesn't appear to be a 7.3.1 tag.
>
> There is a long tradition of systematically failing to tag releases in
> this project. Don't expect it to improve.
Well, I thought I remembered f
Dan Langille <[EMAIL PROTECTED]> writes:
> On Sat, 4 Jan 2003, Peter Eisentraut wrote:
>> There is a long tradition of systematically failing to tag releases in
>> this project. Don't expect it to improve.
> It was I who suggested that a release team would be a good idea.
We *have* a release tea
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> As long as we're spending time on this, why not just write our own version
> of getopt_long()?
Seems like a fine idea to me ... who's volunteering?
regards, tom lane
---(end of broadcast)--
Oliver Elphick <[EMAIL PROTECTED]> writes:
> On Sat, 2003-01-04 at 02:17, Tom Lane wrote:
>> There isn't any simple way to lock *everyone* out of the DB and still
>> allow pg_upgrade to connect via the postmaster, and even if there were,
>> the DBA could too easily forget to do it.
> I tackled thi
> Umm. No. User or system level threads, the statement is true. If a
> thread kills over, the process goes with it. Furthermore, on Win32
Hm. This is a database system. If one of the backend processes dies
unexpectedly, I'm not sure I would trust the consistency and state of the
others.
Or
On Sat, 4 Jan 2003, Peter Eisentraut wrote:
> Greg Copeland writes:
>
> > Just a reminder, there still doesn't appear to be a 7.3.1 tag.
>
> There is a long tradition of systematically failing to tag releases in
> this project. Don't expect it to improve.
It was I who suggested that a release te
Serguei Mokhov writes:
> #if defined(HAVE_GETOPT_LONG)
> #define xo(long,short,desc) printf("%s %s\n", long, desc)
> #else
> #define xo(long,short,desc) printf("%s %s\n", short, desc)
> #endif
>
> seems relatively generic, so it could be used by more than one tool.
As long as we're spending tim
Greg Copeland writes:
> Just a reminder, there still doesn't appear to be a 7.3.1 tag.
There is a long tradition of systematically failing to tag releases in
this project. Don't expect it to improve.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
35 matches
Mail list logo
