On Tue, 2008-09-23 at 22:17 -0700, Joshua D. Drake wrote:
> 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
> >>
greg
On 24 Sep 2008, at 02:45, Tom Lane <[EMAIL PROTECTED]> wrote:
The next big
thing seems to be to figure out exactly how to do multiple references
to CTE outputs, so that we can de-bogotify the planner.
I've looked and don't seem to still have the source tree where I
worked on this. I r
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_contr
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
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:
http://archives.postgresql.org
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...
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 num
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-col
"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
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 p
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 de
"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.
> The
> 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 n
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
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
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
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,
>
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?
>
>
>> 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 a
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.
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 n
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 li
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]
http://sepgsql.googlecode.com/files/sepostgresql-policy-8
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.
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 wi
"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 ha
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
>
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 operatin
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 C
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 for
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 1
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 year
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
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, an
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 implement
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
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 tra
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 toast
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.
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.
>
>
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:
>
> c:/Development/MingW/b
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 var
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.co
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'
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
> > >
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 realise
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 n
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 i
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 entir
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 h
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 li
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
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.
Gevik,
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:
c:/Development/MingW/bin/../lib/gcc/mingw32/3.4.5/../../.
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 re
[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 i
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
> > indep
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
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 s
-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 impo
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
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
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
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 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 sens
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
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
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 (pg
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 t
-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 beca
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 sca
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
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 sta
-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 col
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 pars
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
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
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_attri
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
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib
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 fro
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
[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 uns
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
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,
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.
>
>
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 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 tha
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 fo
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 obsole
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 pg_data
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 th
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 wo
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
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 justif
94 matches
Mail list logo
