Joshua D. Drake wrote:
Andrew Dunstan wrote:
There are in fact very few letters available, as we've been fairly
profligate in our use of option letters in the pg_dump suite.
j and m happen to be two of those that are available.
--max-workers
Perhaps, but please do not use that as justification
On Mon, 2008-09-22 at 15:05 -0400, Andrew Dunstan wrote:
j and m happen to be two of those that are available.
I honestly don't have a terribly strong opinion about what it should be
called. I can live with jobs or multi-threads.
Perhaps we can use -j for jobs and -m for memory, so we can
Hi Darren
On Mon, Sep 22, 2008 at 8:05 PM, Darren Weber
[EMAIL PROTECTED] wrote:
Alternatively, the libpqxx docs say you can set ${PG_CONFIG} to the
path to pg_config, so perhaps you can set that in configure.env (that
sounds like the cleanest option).
I tried this, but it's not working. I
Hi,
Tom Lane wrote:
Yah. However, I started to look at doing this and immediately hit a
stumbling block: we need a representation in pg_depend for a column's
default expression (as distinct from the column itself).
Just to understand the issue here: what's the reason for having an OID
for
Committed.
Tom Lane wrote:
* You should try to get rid of LOCALE_NAME_BUFLEN altogether. Definitely
the comment about it in pg_control.h is now obsolete.
Yep. I removed LOCALE_NAME_BUFLEN. The real max length of a locale name
is now NAMEDATALEN, because it's stored in a name field in
On Mon, Sep 22, 2008 at 10:22:35AM +0300, Heikki Linnakangas wrote:
BTW, the original patch didn't have any provision for creating rows in
pg_collation reflecting the locales available in the OS, but I think
we'd need that. Otherwise the DBA would need to manually run CREATE
COLLATION for
On Tue, Sep 23, 2008 at 10:20 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Committed.
*adds yet another item to his pgAdmin todo list* :-(
Tom Lane wrote:
* You should try to get rid of LOCALE_NAME_BUFLEN altogether. Definitely
the comment about it in pg_control.h is now obsolete.
On Mon, Sep 22, 2008 at 06:11:04PM +0300, Heikki Linnakangas wrote:
This patch should allow to use both system catalog and ICU.
Not without another patch that actually introduces ICU support. What
that would look like, how that would be stored in the catalogs, and
whether we want that is
Martijn van Oosterhout wrote:
On Mon, Sep 22, 2008 at 10:22:35AM +0300, Heikki Linnakangas wrote:
BTW, the original patch didn't have any provision for creating rows in
pg_collation reflecting the locales available in the OS, but I think
we'd need that. Otherwise the DBA would need to manually
On Tue, Sep 23, 2008 at 01:32:38PM +0300, Heikki Linnakangas wrote:
Martijn van Oosterhout wrote:
You're assuming collations are denumerable. They're not. There is no way
to find the list of available collations/locales. You may be able to
guess a few but certainly not all of them.
locale
Martijn van Oosterhout napsal(a):
On Mon, Sep 22, 2008 at 06:11:04PM +0300, Heikki Linnakangas wrote:
This patch should allow to use both system catalog and ICU.
Not without another patch that actually introduces ICU support. What
that would look like, how that would be stored in the catalogs,
Zdenek Kotala wrote:
pg_collation catalog is also important for pg_dump, because system
collation names are not compatible over OS and pg_dump output should be
portable. pg_collation adds abstract layer which solve this problem.
That's a valid point. We'll still need a way to map OS locale to
[resending due to the attachment being too large for the -hackers list --
weren't we going to raise it when we killed -patches?]
Greg Smith [EMAIL PROTECTED] writes:
Using the maximum prefetch working set tested, 8192, here's the speedup
multiplier on this benchmark for both sorted and
Tom Lane [EMAIL PROTECTED] writes:
Greg Sabino Mullane [EMAIL PROTECTED] writes:
Looks like the box-array semicolon got changed to a comma at some point -
attached patch changes it back (\054 to \073)
[ scratches head... ] I seem to have done that in rev 1.198, but I
don't recall why. It's
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom, which Interval TODO items did you complete with this patch?
http://wiki.postgresql.org/wiki/Todo#Dates_and_Times
I think we've at least mostly fixed
* Support ISO INTERVAL syntax if units cannot be determined from the
Greg Smith napsal(a):
On Mon, 22 Sep 2008, Gregory Stark wrote:
I'm quite surprised Solaris doesn't support posix_fadvise -- perhaps
it's in some other version of Solaris?
Solaris has only fake variant of posix_fadvise. See
Markus Wanner [EMAIL PROTECTED] writes:
Just to understand the issue here: what's the reason for having an OID
for the default value and possible another one for a ACLs, but none for
the attribute itself?
Well, as far as the dependency system goes this way is more convenient.
If pg_attribute
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Tue, Sep 23, 2008 at 01:32:38PM +0300, Heikki Linnakangas wrote:
locale -a manages to do it somehow...
Sure, by (on glibc) opening the binary archive and parsing it and then
trying to reverse lookup the alias list. We could ofcourse program
Jeff Davis [EMAIL PROTECTED] writes:
Here is a patch that is an initial attempt to reorganize the parse tree
representation.
Oh dear, we seem to have spent yesterday doing the same work :-(
I'll go over this and try to merge it with my own WIP.
* There are a couple of other rough points in
Tom Lane [EMAIL PROTECTED] writes:
Yeah, I'd been running into that issue too. Adding an explicit pointer
to the CTE into the RTE doesn't work because it renders the parse tree
un-copiable (at least without something a lot more sophisticated than
copyObject; and saving/loading rule
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Tom Lane wrote:
Well, as far as the dependency system goes this way is more convenient.
If pg_attribute entries had their own OIDs it would be fairly hard
to implement DROP TABLE except with an intermediate step of dropping
each of the
Tom Raney wrote:
RELOPTINFO (tenk1): rows=1 width=244
path list:
SeqScan(tenk1) rows=1 cost=0.00..434.00
IdxScan(tenk1) rows=1 cost=0.00..583.25
pathkeys: ((tenk1.unique2, onek.unique2)) ---
cheapest startup path:
Tom Lane wrote:
Martijn van Oosterhout [EMAIL PROTECTED] writes:
On Tue, Sep 23, 2008 at 01:32:38PM +0300, Heikki Linnakangas wrote:
locale -a manages to do it somehow...
Sure, by (on glibc) opening the binary archive and parsing it and then
trying to reverse lookup the alias list. We could
Greg Smith [EMAIL PROTECTED] writes:
On Mon, 22 Sep 2008, Gregory Stark wrote:
Hm, I'm disappointed with the 48-drive array here. I wonder why it maxed out
at only 10x the bandwidth of one drive. I would expect more like 24x or more.
The ZFS RAID-Z implementation doesn't really scale that
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
[ scratches head... ] I seem to have done that in rev 1.198, but I
don't recall why. It's late here though ...
I think my reasoning was that all array types should have typdelim = ','
for consistency. It doesn't actually matter because
Gregory Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
Yeah, I'd been running into that issue too. Adding an explicit pointer
to the CTE into the RTE doesn't work because it renders the parse tree
un-copiable (at least without something a lot more sophisticated than
Markus Wanner [EMAIL PROTECTED] writes:
ISTM that we should at least combine defaults and ACLs then, as proposed
by Stephen.
Huh? Maybe I missed something, but I didn't think that was suggested
anywhere.
regards, tom lane
--
Sent via pgsql-hackers mailing list
Gregory Stark [EMAIL PROTECTED] writes:
Perhaps access paths which expect to be able to prefetch most of their
accesses should use random_page_cost / effective_spindle_count for their i/o
costs?
But then if people don't set random_page_cost high enough they could easily
find themselves with
Tom,
* Tom Lane ([EMAIL PROTECTED]) wrote:
Markus Wanner [EMAIL PROTECTED] writes:
ISTM that we should at least combine defaults and ACLs then, as proposed
by Stephen.
Huh? Maybe I missed something, but I didn't think that was suggested
anywhere.
I had suggested a single table, with an
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I think my reasoning was that all array types should have typdelim = ','
for consistency. It doesn't actually matter because nothing looks at
the value ... the element type's delimiter is what array_in/out use.
Ah, okay, that makes sense. Thanks
Stephen Frost [EMAIL PROTECTED] writes:
Huh? Maybe I missed something, but I didn't think that was suggested
anywhere.
I had suggested a single table, with an OID, which would house anything
that needed a seperate OID for columns (defaults and ACLs currently) in
[EMAIL PROTECTED]
[
Greg Smith [EMAIL PROTECTED] writes:
I have an updated patch I'll be sending along shortly. You might want to test
with that?
Obviously I've got everything setup to test right now, am currently analyzing
your earlier patch and the sequential scan fork that derived from it. If
you've got a
Heikki Linnakangas napsal(a):
Zdenek Kotala wrote:
pg_collation catalog is also important for pg_dump, because system
collation names are not compatible over OS and pg_dump output should
be portable. pg_collation adds abstract layer which solve this problem.
That's a valid point. We'll still
On Tue, 23 Sep 2008, Gregory Stark wrote:
I have *not* been able to observe any significant effect from
POSIX_FADV_SEQUENTIAL but I'm not sure what circumstances it was a problem. It
sounds like it's a peculiar situation which is not easy to reliably reproduce.
Zoltan, Hans-Juergen: would it
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Well, plan B is that we could redefine things as all array types should
have typdelim equal to their base type's typdelim. The backend still
wouldn't care, but if there are other clients out there confusing the
two, maybe this is important
On Mon, 2008-09-22 at 23:06 +0100, Simon Riggs wrote:
On Thu, 2008-09-18 at 10:09 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
On Thu, 2008-09-18 at 09:06 -0400, Tom Lane wrote:
Do we really need a checkpoint there at all?
Timelines only change at shutdown
Robert Haas wrote:
It's too early to vote. :-)
The second and third option have prerequisite.
The purpose of them is to match granularity of access controls
provided by SE-PostgreSQL and native PostgreSQL. However, I have
not seen a clear reason why these different security mechanisms
KaiGai Kohei wrote:
[1] Make a consensus that different security mechanisms have differences
in its decision making, its gulanuality and its scope
I think it is the most straightforward answer.
As operating system doing, DAC and MAC based access controls should be
independently
[EMAIL PROTECTED] (Gevik Babakhani) writes:
It might look like an impossible goal to achieve.. But if there is
any serious plan/idea/ammo for this, I believe it would be very
beneficial to the continuity of PG.
Actually, I imagine that such a rewrite would run a very considerable
risk of
Hot Standby design has been growing on the PostgreSQL Wiki for some
weeks now.
I've updated the design to reflect all feedback received so far on
various topics.
http://wiki.postgresql.org/wiki/Hot_Standby
It's not hugely detailed in every area, but it gives a flavour of the
topics and issues
I'm trying to upgrade my copy of postgresql from 8.2.x to 8.3.4 on a
Windows Vista SP1 laptop. I build postgres using mingw/msys and have had
no issues with 8.1.x and 8.2.x. However, with 8.3.4 I run into problems.
First, building fails:
Gevik Babakhani wrote:
Has there been any idea to port PG to a more modern programming language
like C++? Of course there are some minor obstacles like a new OO design,
this being a gigantic task to perform and rewriting almost everything etc...
I am very interested to hear your opinion.
On Tue, 23 Sep 2008 09:14:33 +0200
Stephen R. van den Berg [EMAIL PROTECTED] wrote:
Joshua D. Drake wrote:
Andrew Dunstan wrote:
There are in fact very few letters available, as we've been fairly
profligate in our use of option letters in the pg_dump suite.
j and m happen to be two of
On Tue, 23 Sep 2008 08:44:19 +0100
Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2008-09-22 at 15:05 -0400, Andrew Dunstan wrote:
j and m happen to be two of those that are available.
I honestly don't have a terribly strong opinion about what it
should be called. I can live with jobs
On Tue, 2008-09-23 at 12:43 -0700, Joshua Drake wrote:
On Tue, 23 Sep 2008 08:44:19 +0100
Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2008-09-22 at 15:05 -0400, Andrew Dunstan wrote:
j and m happen to be two of those that are available.
I honestly don't have a terribly
Chris,
This does not strike me as a particularly useful exercise. If I
intended such a rewrite, I'd much rather consider using something
*interestingly* different from C, like Erlang or Eiffel or Haskell.
And if you were going to do *that*, you'd also rewrite the database to
operate
Simon Riggs wrote:
On Tue, 2008-09-16 at 15:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We keep talking about EXEC_BACKEND mode, though until recently I had
misunderstood what that meant. I also realised that I have more than
once neglected to take it into account
Bruce Momjian wrote:
Simon Riggs wrote:
On Tue, 2008-09-16 at 15:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We keep talking about EXEC_BACKEND mode, though until recently I had
misunderstood what that meant. I also realised that I have more than
once neglected to take it
Magnus Hagander wrote:
Bruce Momjian wrote:
Simon Riggs wrote:
On Tue, 2008-09-16 at 15:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
We keep talking about EXEC_BACKEND mode, though until recently I had
misunderstood what that meant. I also realised that I have more
On Tue, 2008-09-23 at 16:35 -0400, Bruce Momjian wrote:
Simon Riggs wrote:
I can't find anything coherent in docs/readme/comments to explain why it
exists and what its implications are.
It exists because Windows doesn't have fork(), only the equivalent of
fork-and-exec.
Simon Riggs wrote:
On Tue, 2008-09-23 at 12:43 -0700, Joshua Drake wrote:
On Tue, 23 Sep 2008 08:44:19 +0100
Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2008-09-22 at 15:05 -0400, Andrew Dunstan wrote:
j and m happen to be two of those that are available.
I honestly don't
On Tue, 2008-09-23 at 16:50 -0400, Andrew Dunstan wrote:
If we get all that done by November we'll have done well. And we know
that in some cases just this much can lead to reductions in restore
time
of the order of 80%.
Agreed. Go for it.
--
Simon Riggs www.2ndQuadrant.com
Magnus Hagander wrote:
Tom Lane wrote:
We go to some lengths to prevent non-superusers from examining
data_directory and other values that would tell them exactly where the
PG data directory is in the server's filesystem. The recently applied
patch to expose full pathnames of GUC variables'
Charlie Savage wrote:
I'm trying to upgrade my copy of postgresql from 8.2.x to 8.3.4 on a
Windows Vista SP1 laptop. I build postgres using mingw/msys and have had
no issues with 8.1.x and 8.2.x. However, with 8.3.4 I run into problems.
First, building fails:
Tom Lane wrote:
ITAGAKI Takahiro [EMAIL PROTECTED] writes:
I found a bug that pg_controldata ends with error if control files
contain 0x1A (Ctrl+Z) on Windows.
We probably need to add PG_BINARY when we open control files
because 0x1A is an end-of-file marker on Windows.
Well, why is
On Mon, 2008-09-22 at 07:53 -0400, Tom Lane wrote:
Simon Riggs [EMAIL PROTECTED] writes:
I think the issue is identifying the problem. Reading the title of the
post, I think Tom says no to *deleting* the toast table. He also says
no to cleaning the table as part of DROP COLUMN. That still
On Sun, 2008-09-21 at 12:05 -0400, Tom Lane wrote:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
we came across a database where a table had a toasted table,
keeping huge amounts of disk space allocated. However,
the table's current definition didn't explain why there was
a toasted table.
On Thu, 2008-09-18 at 15:59 +0100, Simon Riggs wrote:
On Tue, 2008-09-16 at 10:11 -0400, Alvaro Herrera wrote:
I wonder if the improved clog API required to mark multiple
transactions as committed at once would be also useful to
TransactionIdCommitTree which is used in regular
Bruce,
I think the community's priorities are to add security at the SQL
level, and then we can see clearly what SE-PostgreSQL requires. This
has been discussed before so it should not come as a surprise.
Well, I'm not that clear on exactly the SE implementation, but I spent a
fair amount
Josh Berkus wrote:
Bruce,
I think the community's priorities are to add security at the SQL
level, and then we can see clearly what SE-PostgreSQL requires. This
has been discussed before so it should not come as a surprise.
Well, I'm not that clear on exactly the SE implementation,
Bruce Momjian wrote:
True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.
This makes no sense. We've been sitting for years on the per-row
privilege stuff, and
Have you done anything special to your mingw install?
The only thing different is that I upgraded to the latest mingw and msys
packages a couple of weeks ago. The other thing I can think of is that
I installed openssl and related packages (the official ones from the
msys project). Would
Alvaro Herrera wrote:
Bruce Momjian wrote:
True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.
This makes no sense. We've been sitting for years on the
On Tue, 23 Sep 2008 16:50:43 -0400
Andrew Dunstan [EMAIL PROTECTED] wrote:
Simon Riggs wrote:
On Tue, 2008-09-23 at 12:43 -0700, Joshua Drake wrote:
On Tue, 23 Sep 2008 08:44:19 +0100
Simon Riggs [EMAIL PROTECTED] wrote:
On Mon, 2008-09-22 at 15:05 -0400, Andrew Dunstan
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.
This makes no sense. We've been sitting
Attached is the result of a couple of days hacking on the WITH RECURSIVE
patch. This moves us a lot closer to having sanity in the parsing
phase, though I'm still quite unhappy with the second half of the
processing in parse_cte.c. I added some infrastructure to make the
first half's search for
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, why is that a bug? If the platform is so silly as to define text
files that way, who are we to argue?
The problem is that our pg_controldata might have binary values that
contain 0x1a that will be confused by the operating system
Hannu Krosing [EMAIL PROTECTED] writes:
On Sun, 2008-09-21 at 12:05 -0400, Tom Lane wrote:
The DROP COLUMN form does not physically remove the column, but
simply makes it invisible to SQL operations. Subsequent insert and
update operations in the table will store a null value for the
column.
Greg Sabino Mullane [EMAIL PROTECTED] writes:
DefineType currently always sets the array's typdelim to ',', so I
figured that the built-in types should match that. But we could
easily change both of them to do the other. Thoughts?
I'd slightly lean towards keeping it the way it has been
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, why is that a bug? If the platform is so silly as to define text
files that way, who are we to argue?
The problem is that our pg_controldata might have binary values that
contain 0x1a that
Andrew Dunstan [EMAIL PROTECTED] writes:
Tom Lane wrote:
pg_controldata is certainly already being read as binary.
Umm, no, it is in the backend I believe but not in the utilities. Hence
the original bug report. We need to add the binary flag in
pg_controldata.c and pg_resetxlog.c.
Ah,
I updated the series of patches for SE-PostgreSQL 8.4devel.
[1/5]
http://sepgsql.googlecode.com/files/sepostgresql-sepgsql-8.4devel-3-r1043.patch
[2/5]
http://sepgsql.googlecode.com/files/sepostgresql-pg_dump-8.4devel-3-r1043.patch
[3/5]
The following proposal is idea which I have been considered for several days.
A design of PostgreSQL fine-grained security
* Target
This feature provide a row-level access control feature based on
database acl. Any tuple can have its access control
Bruce Momjian wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
True, but think we would like to have all the SQL-level stuff done
first, or at least decide we don't want it at the SQL level, before
moving forward with adding fine-grained controls.
This makes no sense. We've
Josh Berkus [EMAIL PROTECTED] writes:
Multilevel frameworks have concepts of data hiding and data substitution
based on labels. That is, if a user doesn't have permissions on data,
he's not merely supposed to be denied access to it, he's not even supposed
to know that the data exists. In
Well, does it make sense to add column-level privileges just for
SE-Linux?
That's the wrong question. The question here is: does it make sense to
have per-row permissions implemented on top of an abstraction layer
whose sole current implementation is SE-Linux?
Er, Bruce was asking about
Robert Haas wrote:
C isn't going anywhere anytime soon. Look at its history, it has survived
its 'replacements' over and over again. The most popular kernels, shells
and applications are all still written in C (new and old). Where are the
warning signs that it is dwindling?
To add to
Robert Haas wrote:
I think the answer is yes, because (as others have said) if we ever want
to have SQL-level per-row permissions, then we can implement them with
no change to the patch currently in discussion.
If that's true, it weighs somewhat in favor of accepting this patch,
but how
Hey does anybody know how to call stored procedure written in pgsql using
hibernate concecpt with java application... I wanted to know how mapping
takes place. Please could anybody help me out
Tom Lane wrote:
Josh Berkus [EMAIL PROTECTED] writes:
Multilevel frameworks have concepts of data hiding and data substitution
based on labels. That is, if a user doesn't have permissions on data,
he's not merely supposed to be denied access to it, he's not even supposed
to know that the
On Tue, Sep 23, 2008 at 11:53 PM, chetan N [EMAIL PROTECTED] wrote:
Hey does anybody know how to call stored procedure written in pgsql using
hibernate concecpt with java application... I wanted to know how mapping
takes place. Please could anybody help me out
This is the wrong mailing
Yeah, that's what I keep hearing that the spooks think they want.
I can't imagine how it would play nice with SQL-standard integrity
constraints. Data that apparently violates a foreign-key constraint,
for example, would give someone a pretty good clue that there's
something there he's not
Robert Haas [EMAIL PROTECTED] writes:
That's the wrong question. The question here is: does it make sense to
have per-row permissions implemented on top of an abstraction layer
whose sole current implementation is SE-Linux?
Er, Bruce was asking about per-column, not per-row.
There's a
On Tuesday 23 September 2008 14:15:34 Simon Riggs wrote:
Hot Standby design has been growing on the PostgreSQL Wiki for some
weeks now.
I've updated the design to reflect all feedback received so far on
various topics.
http://wiki.postgresql.org/wiki/Hot_Standby
It's not hugely detailed
Bruce Momjian wrote:
Robert Haas wrote:
I think the answer is yes, because (as others have said) if we ever want
to have SQL-level per-row permissions, then we can implement them with
no change to the patch currently in discussion.
If that's true, it weighs somewhat in favor of accepting this
Robert Haas [EMAIL PROTECTED] writes:
I don't think there's much point in second-guessing the NSA: they are
smart and have thought about this more than we have.
No doubt, but have they told us what we'd need to know to make a
non-broken implementation? I haven't seen anything about how a SQL
Tom Lane wrote:
Robert Haas [EMAIL PROTECTED] writes:
That's the wrong question. The question here is: does it make sense to
have per-row permissions implemented on top of an abstraction layer
whose sole current implementation is SE-Linux?
Er, Bruce was asking about per-column, not
Simon Riggs wrote:
On Tue, 2008-09-23 at 16:50 -0400, Andrew Dunstan wrote:
If we get all that done by November we'll have done well. And we know
that in some cases just this much can lead to reductions in restore
time
of the order of 80%.
Agreed. Go for it.
Just as an FYI, by far the
Magnus Hagander wrote:
exec(locale -a) ...
I suppose we'd need something else for Windows, but I'm sure there's
a way.
IIRC, the data is in the registry. Should be enumerable somehow - we'll
have to do it platform specific of course, but it's not the first time
we'd do that for windows...
I am re-sending this message to -hackers from yesterday, because the
first time it didn't appear to make it through. This time I gzipped the
patch. This is just for the archives (and to give context to the
replies), and this message is superseded by Tom's patch here:
Petr Jelinek wrote:
Magnus Hagander wrote:
exec(locale -a) ...
I suppose we'd need something else for Windows, but I'm sure there's
a way.
IIRC, the data is in the registry. Should be enumerable somehow - we'll
have to do it platform specific of course, but it's not the first time
we'd do
Andrew Dunstan wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
Well, why is that a bug? If the platform is so silly as to define text
files that way, who are we to argue?
The problem is that our pg_controldata might have binary values
92 matches
Mail list logo
