Tom Lane wrote:
Well, in general the *variable* parts of the banner were all put there
because of fairly urgent need, and I'd resist removing them. It's the
unchanging boilerplate that seems open to debate.
I'm +1 for cutting that down to a single line. I don't care one way or
the other
Tom Lane wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
I think that it would be great if the pg_timezone_names and
pg_timezone_abbrevs included a boolean field indicating if that item is
in the Olsen DB
Huh? They're all in the Olsen DB
Not true, the zone.tab file has 398 zones
Alvaro Herrera wrote:
Naz Gassiep wrote:
It may also be beneficial to add the ISO 3166 column into that view, the
data is in zone.tab and I can't see a reason to not include it.
We also have the country name in iso3166.tab and the geo coordinates.
And there is also a comment field
I brought this up a while ago, but I didn't get any responses, I assume
due to everyone being too busy with 8.3
I think that it would be great if the pg_timezone_names and
pg_timezone_abbrevs included a boolean field indicating if that item is
in the Olsen DB or if it is a system alias or
Is there any reason that the zone.tab information is not included in the
pg_timezone_names system view? ISTM that there is really no reason not
to, as that view is really populated using that file anyway. There is a
1:1 mapping (assuming the aliases are mapped to the zone.tab entries
they are
data and other standardized data sources easier, as you
could be confident that all timezone names matched the data in the CLDR.
I think what I'm trying to say is that using and applying standards is a
good thing.
- Naz.
Naz Gassiep wrote:
Is there any reason that the zone.tab information
The problem with forcing authentication is that an auth-unaware client
connecting to a legitimate postmaster would have its connections
refused. That same client would have its connections accepted by an
impostor postmaster. Thus, there is no way to stop impostor postmasters
from carrying out
Wow... not sure how I missed that. I *did* create this schema ages ago,
perhaps it wasn't there, or at the time I had no idea what the
implications were. *shrug*
Regards,
- Naz.
Tom Lane wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
As a result, when creating tables containing
Actually I think the *most* important thing to work on is to get hash to
the point where its search speed actually beats btree consistently, so
that it has an excuse to live. If that is insoluble we might well end up
ripping it out entirely. (The first three TODO items for hash indexes
are
Just a question, is there any advantage to having this then building a
function in applications that wrap and use pg_dump with a few options?
Surely that's a more appropriate way to achieve this functionality?
- Naz.
Usama Munir wrote:
Hi,
i was following a thread some time ago where adding a
Andrew Dunstan wrote:
Naz Gassiep wrote:
I believe the suggestion was to have an automated process that only ran
on known, sane patches.
How do we know in advance of reviewing them that they are sane?
Same way as happens now. I would assume this mechanism would only be
applied to patches
What is approved to contrib?
The problem here is that having reasonable certainty that a patch is
not malicious requires having gone over it in some detail; at which
point you might as well apply the thing. Or if you didn't apply it,
you bounced it for reasons that are unlikely to have
I believe the suggestion was to have an automated process that only ran
on known, sane patches. I don't think he was suggesting a mechanism for
the great unwashed masses to dump arbitrary code into and have it
applied in the buildfarm. You'd have an inventory of patches (you could
use a hash to
A few of us on IRC were wondering what the status of tsearch2 is in 8.3 ?
Was it decided to include it in core or did we decide to keep FTS as a
plugin?
Some brief comments from anyone on the inside of the whole FTS issue
would be greatly appreciated by us mere end users.
Regards,
- Naz.
Granted, but a configure switch would allow users who want to use OS TZ
file in conjunction with a compiled from source installation. Many
users of OSes with package managers such as Debian or RedHat may, for
whatever reason, want to use a source tarball to install and also use
the OS TZ list.
I do see your points regarding the existence of use cases for this
feature, and I agree that at worst, the implementation of this feature
would provide a way to greatly simplify query design and at best provide
a whole new method of obtaining decision supporting data from a
relational
I would be *very* concerned that system time is not a guaranteed
monotonic entity. Surely a counter or other internally managed mechanism
would be a better solution.
Furthermore, what would be the ramifications of master and slave system
times being out of sync?
Finally what if system time
Andrew Dunstan wrote:
I am constantly running into this:
Q. Does PostgreSQL have full text indexing?
A. Yes it is in contrib.
Q. But that isn't part of core.
A. *sigh*
Where on the website can I see what plugins are included with
PostgreSQL?
Where on the website can I see the Official
At risk of being chastised for reviving old issues, I was wondering,
what are the chances were of getting the dump / restore selectivity into
8.2 ? I am referring to the idea that, instead of the current 2 parts, a
dump could be broken up into 3 parts, namely tables, data and everything
else,
Zero, because feature freeze is over.
Aah yes, fair enough
If you find this feature interesting, you are free to drive the development
yourself, independent of it appearing on any list. To avoid tears later on,
look for a consensus about the merit of the feature first, though
This has
None, but feel free to start coding for 8.3.My coding skills are still nascent,
but I shall do my best.
My coding skills are still pretty nascent, but I shall do my best.
That seems like a rather spectacular overstatement of the likely
benefits, not to mention a misdescription of what was
Any chance for a DB Client accessible list of allowable time zones? I've
been told that the only way to get at this list is by looking through
the source and lifting the list from zone.tab.
While I'm at it, how about an accessible list of country codes? I know
that it's not core db
Martijn van Oosterhout wrote:
In the CVS version there is a table with this information:
http://developer.postgresql.org/pgdocs/postgres/view-pg-timezonenames.html
Great, thanks for that
Err, where does postgres use this information? I beleive there is a
project on pgfoundary that has
Actually, what that view gives you is timezone offset abbreviations, not
the full zone names that you could use with SET TIME ZONE. It strikes
me that we should have a view for that as well. We could use code
similar to scan_available_timezones() to generate the view output.
It's somewhat
I have a PostgreSQL installation on a Debian box that had the 64bit SMP
kernel installed before PostgreSQL was compiled and installed on it.
Does PostgreSQL take any advantage of the 64 bit environment or have we
not done anything to move into the 64 bit world yet?
Regards,
- Naz
Douglas McNaught wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
I have a PostgreSQL installation on a Debian box that had the 64bit
SMP kernel installed before PostgreSQL was compiled and installed on
it. Does PostgreSQL take any advantage of the 64 bit environment or
have we
Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
Well, the other issue is how many canned breakup schemes we are going to
support. If this particular one is of sufficiently general usefulness
then I have no objection. But when you can produce it trivially from the
This is my first post to a PostgreSQL mailing list, so please forgive me
if I have posted to the wrong place
Currently pg_dump has flags for dumping only table definitions and/or
data. These flags are respectively:
--schema-only
--data-only
I propose that two more be added:
--tables-only
Tom Lane wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
I propose that two more be added:
--tables-only
--constraints-only
This doesn't seem well-defined at all. There are many objects in a
database that are definitely neither tables nor constraints, and it's
not very
Andreas Joseph Krogh wrote:
On Friday 18 August 2006 18:52, Tom Lane wrote:
Naz Gassiep [EMAIL PROTECTED] writes:
I propose that two more be added:
--tables-only
--constraints-only
This doesn't seem well-defined at all. There are many objects
Andrew Dunstan wrote:
We already have a highly selective and configurable restore mechanism,
using the -L feature of pg_restore. Maybe there's a good special case
for this particular split, but it is hardly undoable now.
As for Naz' needs - I gave him a perl script I whipped up in few
31 matches
Mail list logo
