Already have :)
Joshua D. Drake
--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy
Bernd Helmle
Modified Files:
--------------
pgsql/src/backend/utils/mb/conversion_procs:
Makefile (r1.19 -> r1.20)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/mb/conversion_procs/Makefile?r1=1.19&r2=1.20)
pgsql/src/include/catalog:
catversion.h (r1.478 -> r1.479)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/catversion.h?r1=1.478&r2=1.479)
pg_proc.h (r1.510 -> r1.511)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/catalog/pg_proc.h?r1=1.510&r2=1.511)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
---------------------------------------------------------------------------
Bernd Helmle wrote:
>
> Please find attached a patch that adds some missing descriptions for
> aggregates, functions and conversions. This will add COMMENTs to the
> conversion sql script as well. Most of the descriptions are taken from the
> documentation (especially for the statistic functions). I didn't bother
> with some internal functions like text_pattern_lt, if we agree they should
> be described as well i can add them, too.
>
> --
> Thanks
>
> Bernd
[ Attachment, skipping... ]
>
> --
> Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-patches
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
OK, so this is a standards issue, then, OK, makes sense.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> On Sat, Aug 23, 2008 at 10:28 AM, Ivan Sergio Borgonovo
> <mail@webthatworks.it> wrote:
> > On Fri, 22 Aug 2008 18:34:53 -0600
> > "Scott Marlowe" <scott.marlowe@gmail.com> wrote:
> >
> >> Glad you got your problem resolved. I have to admit I tend to
> >> mostly use psql to interact with postgres. Nothing against
> >> PGAdmin III, it's good software. I just tend to feel more comfy
> >> scripting things than clicking things. Whether you're using
> >> pgadmin III or psql, it's important that you have the right
> >> version. For pgadmin it's usually best to always have the
> >> latest version, and with psql the one that matches your db.
> >
> > Is there any secret I don't know?
> > I mostly use pgadmin because:
> > 1) It is easier to cut and paste code and results
>
> I use /i /o a lot. poor man's cut and paste / multi-file buffer.
> also highlight / middle button click.
I just forgot that vim is vim:
http://www.vim.org/scripts/script.php?script_id=356
Object Completion
----------------------------
dbext ties into Vim dictionary feature. You can complete table
names, procedure names and view names using the i_CTRL-X_CTRL-K
feature.
Viewing Lists of Objects
------------------------------------
You can browse through the various objects in the database you are
connected to and specify wildcard information. For example you can
say, "Show me all tables beginning with 'ml_' ". These objects are
currently supported: Tables, Procedures, Views, Columns (for a
table).
Trying to make it work.
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
GRANT/REVOKE behavior is specified by the standard, whereas the stuff
we allow under ALTER VIEW is all an extension to the standard --- not
merely syntax-wise, but functionality.
A concrete reason not to do it is that if someone writes GRANT ON VIEW,
their code won't port to other DBs that are following the spec, and
it'll be only because we allowed non-spec syntactic sugar, not because
they're using functionality not covered by the spec.
We routinely complain about mysql inventing nonstandard ways to express
things that have perfectly good spec-compliant equivalents. How would
this be different?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Why not just use some standard record syntax, like
SELECT(value::type name, ...)
or perhaps some extended ROW() or VALUES() syntax ?
Like this :
SELECT * FROM FUNC(SELECT(value::type name, ...) AS r);
-----------------
Hannu
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
>> Can you modify the buildfarm's description of that machine to mention
>> the special malloc debug flags? It'd probably stop me from asking
>> you this question again ;-)
>
> hmm - would take somebody with SQL-level access to do this - the script
> to update OS/compiler related data is only partially(ie not updating all
> information) working...
I've changed the compiler to read gcc-malloc-FGJPZ on spoonbill.
BTW this animal has not updated in quite a few days ... is this
expected?
> But maybe it would be nice to have some sort of "notes about this
> buildfarm member" text field that contains this information (or other
> stuff like "this is a VM running on bar" or "this is really the same
> hardware as animal bar just with configuration baz" ?
Apparently Andrew has been working on it, but it's not yet visible on
the web page anywhere.
--
Alvaro Herrera http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Yes, I assumed we were following the recent work on ALTER TABLE/VIEW
with GRANT/REVOKE. Peter, Tom, how is GRANT/REVOKE different?
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Each INDEX create a delay on INSERT. Try to measure performance w/o any
> indexes.
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
Regards
Loïc
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Oracle: fce (param => expr)
MSSQL: fce @param = expr
Firebird 2.0 allows defaults, but doesn't support named params
> At any point in this discussion has anyone explained why these labels would
> actually be a good idea?
>
it's allows smart libraries like SQL/XML
regards
Pavel Stehule
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's 24x7 Postgres support!
>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I fail to understand why it's advantageous to artificially create
surprising behavior. There are cases where PostgreSQL now accepts
either ALTER VIEW or ALTER TABLE where it previously accepted only the
latter, so the situation is hardly without precedent. I find it
exceedingly unlikely that anyone is relying on GRANT ON VIEW to NOT
work.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
I don't prefer this way
regards
Pavel Stehule
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> PgUS will have a store, I assume PgEU will as well but I can not speak
> for them.
You need to talk to your tax accountant about this then. There are special
rules around 501(c)3s selling things.
--
Josh Berkus
PostgreSQL
San Francisco
--
Sent via pgsql-advocacy mailing list (pgsql-advocacy@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-advocacy
Yeah, that's the core of my objection.
Also, having now looked at the proposed patch, it seems clear that it
isn't addressing the issue of quoting/escaping at all; so I wonder how
this can be considered to be a safely machine-readable format.
In particular, the output seems to me to not even approximate the rules
laid down at
http://docutils.sourceforge.net/docs/user/rst/quickref.html
which among other things requires backslashing of literal asterisk,
backquote, vertical bar, and underscore in order to avoid textual data
looking like it matches the format's inline-markup constructs.
So, quite aside from the question of whether we care to support ReST,
my opinion is that this patch fails to do so, and a significantly more
invasive patch would be needed to do it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
OK, removed from TODO.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Not just non-profits, either. We're a social species, and we're
motivated at a powerful, primitive level by messages to the effect of,
"lots of others like you are doing this."
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www
I use /i /o a lot. poor man's cut and paste / multi-file buffer.
also highlight / middle button click.
> 2) It's easier to open several connections
I just use multiple term windows
> 3) you've the object structure to navigate
that's the main reason I'd find myself using it.
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Thank you for an early check. !
I understand that many users think are same with you.
more gratitude:-)
Regards,
Hiroshi Saito
----- Original Message -----
From: "Eric P. Melbardis" <eric.melbardis@netkitsolutions.com>
Hi
Testing on my home system, looking good... will try on my office system Monday.
Note:
I am assuming that the uuid will mostly be used as a primary key on records that
will exist in replicated databases to guarantee uniqueness. The problem that is see with the
current uuid functions for this purpose is that the generated uuid is very random causing
great performance issues with the index; at least when using oracle and ms sql server, did
not try with postgres, but must be similar. Usually inserting random data into an index of
any kind is a worst case stress test. Hence the older style of uuid, based on mac addresses
and time tend to generate more sequential uuid's, at least when inserting a bunch of records
at once.
In other words it would be nice to have the old fashioned style of uuid's.
Regards
Eric
-----Original Message-----
From: Hiroshi Saito [mailto:z-saito@guitar.ocn.ne.jp]
Sent: Saturday, August 23, 2008 8:26 AM
To: Eric P. Melbardis; Bruce Momjian
Cc: Nicolas ANTONINI; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4274: uuid returns duplicate values
Hi Eric-san.
Done! please check it.
http://winpg.jp/~saito/pg_work/OSSP_win32/pg8.3.3-win-bin-uuid-ossp-20080824.zip
I checked by the following machine.
-- Disktop(Windows-XP SP2)
Pentium(R) 4 CPU 2.6GHz
Memory 2GB
-- Notebook(Windows-XP SP2)
Pentium III CPU 495 MHz
Memory 256MB
--
Thanks.
Regards,
Hiroshi Saito
----- Original Message -----
From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>
> Ooops, Please wait for this.
>
>> Please try this.(The date of a binary is 7/8)
>> http://winpg.jp/~saito/pg_work/OSSP_win32/pg8.3.3-win-bin-uuid-ossp-20080823.zip
>> I will arrange thoroughly again.
>
> Anyhow, I have only now stale development environment.
> The time of a check is still required. thanks.
>
> Regards,
> Hiroshi Saito
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
> Is this a TODO?
We already fixed it:
2008-07-07 14:09 tgl
* src/backend/utils/adt/: date.c, timestamp.c (REL8_1_STABLE),
date.c, timestamp.c (REL8_3_STABLE), date.c, timestamp.c
(REL8_2_STABLE), date.c, timestamp.c: Fix AT TIME ZONE (in all
three variants) so that we first try to interpret the timezone
argument as a timezone abbreviation, and only try it as a full
timezone name if that fails. The zic database has four zones (CET,
EET, MET, WET) that are full daylight-savings zones and yet have
names that are the same as their abbreviations for standard time,
resulting in ambiguity. In the timestamp input functions we
resolve the ambiguity by preferring the abbreviation, and AT TIME
ZONE should work the same way. (No functionality is lost because
the zic database also has other names for these zones, eg
Europe/Zurich.) Per gripe from Jaromir Talir.
Backpatch to 8.1. Older releases did not have the issue because AT
TIME ZONE only accepted abbreviations not zone names. (Thus, this
patch also arguably fixes a compatibility botch introduced at 8.1:
in ambiguous cases we now behave the same as 8.0 did.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> Glad you got your problem resolved. I have to admit I tend to
> mostly use psql to interact with postgres. Nothing against
> PGAdmin III, it's good software. I just tend to feel more comfy
> scripting things than clicking things. Whether you're using
> pgadmin III or psql, it's important that you have the right
> version. For pgadmin it's usually best to always have the latest
> version, and with psql the one that matches your db.
Is there any secret I don't know?
I mostly use pgadmin because:
1) It is easier to cut and paste code and results
2) It's easier to open several connections
3) you've the object structure to navigate
But I miss psql auto completion.
I know I can call an external editor that would make cut&paste
easier in psql but I'll lose autocompletion and I've had some issues
with pgadmin search&replace and regexp, so I definitively would
enjoy psql more... but what about the rest?
--
Ivan Sergio Borgonovo
http://www.webthatworks.it
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
> SELECT tags from zettelkasten where 'Sozialpsychologie' ~* any(tags) order by
> ident;
Did you look at the matches? I suspect this isn't behaving even
remotely the way you want, because ~* expects the pattern operand
on the right.
Since there's no SQL syntax with ANY() on the left of the comparison
operator, what you'd need to do to make this work is invent a "reverse
regex" operator that switches its arguments. That'd be pretty trivial
to do with a one-line plpgsql function under it. (I'm not sure what
performance would be like though; as the table grows you might find
yourself needing to change the reversing function to C.)
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
You're going to have a hard time making parentheses affect the behavior
if you do it that way.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> While we don't _need_ it, it would make our system more consistent; we
> have made similar changes for views in other areas.
I'm not sure it'd make the system more consistent. Because the SQL
standard says you use GRANT ON TABLE for a view. we'd have to always
ensure that we accepted that; whereas in at least some other places
we are trying to be picky about TABLE/VIEW/SEQUENCE actually matching
the object type.
Given the spec precedent, I'm inclined to leave it alone. It's not like
there aren't plenty of other SQL quirks that surprise novices.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
> Hello
>
> 2008/8/23 Peter Eisentraut <peter_e@gmx.net>:
>> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>>> If we're really worried about it we can have a GUC for a few versions
>>> that turns off named parameter assignment. But I don't think we
>>> should compromise the design on the theory that some folks might be
>>> using that as an operator *and* can't change their application to
>>> wrap it's use in ().
>>
>> Even if that were a reasonable strategy, you can't use GUC parameters to alter
>> parser behavior.
>
> I thing, so it's possible - in this case. We should transform named
> params to expr after syntax analyze.
So for a bit of useless syntactic sugar we should introduce conflicts with
named parameters, conflicts with operators, introduce an un-sqlish syntax and
remove a feature users have already made use of and introduce backwards
compatibility issues for those users?
At any point in this discussion has anyone explained why these labels would
actually be a good idea?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Oops. I've now put it up with some minor edits and formatting at
<http://wiki.postgresql.org/wiki/CTEReadme>. It is linked from the
Commitfest page.
> > Also, now that we are into August, would Asaba-san and whomever else
> > like to try out the git repository? To do so, I just need a login
> > name and a public key.
>
> I will send you later.
Thanks :)
Cheers,
David.
--
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fetter@gmail.com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
2008/8/23 Peter Eisentraut <peter_e@gmx.net>:
> On Friday 22 August 2008 07:41:30 Decibel! wrote:
>> If we're really worried about it we can have a GUC for a few versions
>> that turns off named parameter assignment. But I don't think we
>> should compromise the design on the theory that some folks might be
>> using that as an operator *and* can't change their application to
>> wrap it's use in ().
>
> Even if that were a reasonable strategy, you can't use GUC parameters to alter
> parser behavior.
>
I thing, so it's possible - in this case. We should transform named
params to expr after syntax analyze.
Pavel
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
*-------------------------------------------------------*
*-Edwin Quijada
*-Developer DataBase
*-JQ Microsistemas
*-809-849-8087
* " Si deseas lograr cosas excepcionales debes de hacer cosas fuera de lo comun"
*-------------------------------------------------------*
> Date: Thu, 21 Aug 2008 14:00:52 -0500
> From: jcasanov@systemguards.com.ec
> To: ra_duque@yahoo.com.mx
> Subject: Re: [pgsql-es-ayuda] NOTIFY del log ??
> CC: pgsql-es-ayuda@postgresql.org
>
> 2008/8/21 Raul Andres Duque :
>> Quisiera crear una herramienta "similar" al SQL PROFILER de MSSQL
>
> y que hace esa herramienta?
>
>
> --
> Atentamente,
> Jaime Casanova
> Soporte y capacitación de PostgreSQL
> Asesoría y desarrollo de sistemas
> Guayaquil - Ecuador
> Cel. (593) 87171157
> --
> TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
_________________________________________________________________
Reveal your inner athlete and share it with friends on Windows Live.
http://revealyourinnerathlete.windowslive.com?locale=en-us&ocid=TXT_TAGLM_WLYIA_whichathlete_us--
TIP 2: puedes desuscribirte de todas las listas simultáneamente
(envía "unregister TuDirecciónDeCorreo" a majordomo@postgresql.org)
Done! please check it.
http://winpg.jp/~saito/pg_work/OSSP_win32/pg8.3.3-win-bin-uuid-ossp-20080824.zip
I checked by the following machine.
-- Disktop(Windows-XP SP2)
Pentium(R) 4 CPU 2.6GHz
Memory 2GB
-- Notebook(Windows-XP SP2)
Pentium III CPU 495 MHz
Memory 256MB
--
Thanks.
Regards,
Hiroshi Saito
----- Original Message -----
From: "Hiroshi Saito" <z-saito@guitar.ocn.ne.jp>
> Ooops, Please wait for this.
>
>> Please try this.(The date of a binary is 7/8)
>> http://winpg.jp/~saito/pg_work/OSSP_win32/pg8.3.3-win-bin-uuid-ossp-20080823.zip
>> I will arrange thoroughly again.
>
> Anyhow, I have only now stale development environment.
> The time of a check is still required. thanks.
>
> Regards,
> Hiroshi Saito
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
> Please try this.(The date of a binary is 7/8)
> http://winpg.jp/~saito/pg_work/OSSP_win32/pg8.3.3-win-bin-uuid-ossp-20080823.zip
> I will arrange thoroughly again.
Anyhow, I have only now stale development environment.
The time of a check is still required. thanks.
Regards,
Hiroshi Saito
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Well, Tom has raised a question about its need and Asko has questioned
whether it should be under a different setting but so far no one has
outright rejected the proposal. Does anyone else have an opinion? I am
attaching a patch for further review.
--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
This is not valid for PGDG RPMs :) As I wrote, it will be in 8.4 set.
>
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
You may want to change log_filename option, and set it to (for example)
"postgresql-%a.log" so that ogs will be rotated weekly.
Actually this is what I'm planning to do for 8.4+ PGDG RPMs.
Regards,
--
Devrim GÜNDÜZ
devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr
http://www.gunduz.org
----- Original Message -----
From: "Bruce Momjian" <bruce@momjian.us>
> Hiroshi Saito wrote:
>> Hi.
>>
>> Yes, Finally Ralf-san adjusts this patch.
>> http://winpg.jp/~saito/pg_work/OSSP_win32/.
>> Therefore, it is contained in the next release.(1.6.3/4)
>
> OK, good. Does any of this get applied to contrib/uuid-ossp?
There is nothing, uuid-ossp has an official release place. It will evolve uniquely.
Ralf-san supplies a great module to us.!:-)
As for try-uuidwin32 (native-uuid of winapi), it is not suitable to contrib.
However, It may be pgfoundry supposing it is desired.
Thanks!
Regards,
Hiroshi Saito
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
While we don't _need_ it, it would make our system more consistent; we
have made similar changes for views in other areas.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Ehh?..ugaa..sorry..
I made some mistakes, when it probably worked.
Please try this.(The date of a binary is 7/8)
http://winpg.jp/~saito/pg_work/OSSP_win32/pg8.3.3-win-bin-uuid-ossp-20080823.zip
I will arrange thoroughly again.
Thanks!
Regards,
Hiroshi Saito
----- Original Message -----
From: "Eric P. Melbardis" <eric.melbardis@netkitsolutions.com>
Hi
I downloaded the latest version from the specified url.
Put dll in the postgres "C:\Program Files\PostgreSQL\8.3\lib" directory, and restarted
postgres service
Sorry, still does not work!
nkworks3=# SELECT test_uuid(10);
INFO: uuid = a1942895-bdb4-484a-a3fd-6b90e7652d8c
INFO: uuid = f2b4a00f-52a0-4a63-aac0-0500b9e6d438
INFO: uuid = f2b4a00f-52a0-4a63-aac0-0500b9e6d438
INFO: uuid = c6607966-0685-4d09-87f5-c593f3dd8924
INFO: uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO: uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO: uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO: uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO: uuid = b52c719e-6484-49e6-87db-d885d45d7313
INFO: uuid = b52c719e-6484-49e6-87db-d885d45d7313
test_uuid
-----------
(1 row)
Regards
Eric
-----Original Message-----
From: Hiroshi Saito [mailto:z-saito@guitar.ocn.ne.jp]
Sent: Thursday, August 21, 2008 8:03 PM
To: Bruce Momjian
Cc: Eric P. Melbardis; Nicolas ANTONINI; pgsql-bugs@postgresql.org
Subject: Re: [BUGS] BUG #4274: uuid returns duplicate values
Hi.
Yes, Finally Ralf-san adjusts this patch.
http://winpg.jp/~saito/pg_work/OSSP_win32/.
Therefore, it is contained in the next release.(1.6.3/4)
Thanks!!
Regards,
Hiroshi Saito
----- Original Message -----
From: "Bruce Momjian" <bruce@momjian.us>
> Hiroshi Saito wrote:
>> Hi.
>>
>> This can obtain a comfortable result.
>> http://winpg.jp/~saito/pg_work/OSSP_win32/pg8.3.3-win-bin-uuid-ossp-20080706.zip
>>
>> I will adjust with Rarf-san.
>
> Has this been completed?
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
The bottom range of Unicode codepoints is the same as ISO 8859-1, but not the
bottom range of UTF-8 encoded bytes.
--
Sent via pgsql-www mailing list (pgsql-www@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-www
Of course. Now that I understand it's blindingly obvious that the
double quotes above are part of the string and the insert would be;
INSERT INTO table (hfield) VALUES ('"a"=>"b"');
> " character was chosen to simplify escaping,
To prevent;
INSERT INTO table (hfield) VALUES ('''a''=>''b''');
I guess my brain was pointed elsewhere when I asked. Thanks for not
treating me like an idiot. :-)
--
D'Arcy J.M. Cain <darcy@druid.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
The SQL standard doesn't specify it. And there is no need for it.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
yes
>
> ---------------------------------------------------------------------------
>
> Peter Eisentraut wrote:
> > Am Mittwoch, 9. Juli 2008 schrieb Peter Eisentraut:
> > > I propose that we relax these two checks to test for
> > > binary-coercibility instead, which is effectively what is expected and
> > > required here anyway.
> >
> > Here is the corresponding patch.
>
> [ Attachment, skipping... ]
>
> > --
> > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> > To make changes to your subscription:
> > http://www.postgresql.org/mailpref/pgsql-hackers
>
> --
> Bruce Momjian <bruce@momjian.us> http://momjian.us
> EnterpriseDB http://enterprisedb.com
>
> + If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Even if that were a reasonable strategy, you can't use GUC parameters to alter
parser behavior.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
SELECT tags from zettelkasten where 'Sozialpsychologie' ~* any(tags) order by
ident;
delivers 7 rows
SELECT tags from zettelkasten where 'SoziALPSychologie---FOOBARBAZ' ~* any(tags)
order by ident;
also delivers 7 rows,
however:
SELECT tags from zettelkasten where 'sozial' ~* any(tags) order by ident;
delivers 0 rows.
So how do I select all entries from "zettelkasten" tagged with
e.g. '*psycholog*'?
PS: Keep me CC:'ed, I am not subscribed to this list
mit freundlichen Grüßen
Stefan Schumacher
--
https://deepsec.net/schedule/
Desing and Implementation of Security Awareness Campaigns at
DeepSec Security Conference Vienna/Austria 2008-11-11
recent(upcoming 2.9.22) powerdns code actually does have dnssec support
(a bit limited though).
On the other hand getting your typical database backed DNS-managment GUI
to grok DNSSEC is probably turing out to become a challenge.
Stefan
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Remove tuple's killing by killtuple() if tuple was moved to another
page - it could produce unaceptable overhead.
Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support.
Tags:
----
REL8_1_STABLE
Modified Files:
--------------
pgsql/src/backend/access/gist:
gistget.c (r1.52.2.1 -> r1.52.2.2)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistget.c?r1=1.52.2.1&r2=1.52.2.2)
gistscan.c (r1.61 -> r1.61.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistscan.c?r1=1.61&r2=1.61.2.1)
pgsql/src/include/access:
gist_private.h (r1.8 -> r1.8.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gist_private.h?r1=1.8&r2=1.8.2.1)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Remove tuple's killing by killtuple() if tuple was moved to another
page - it could produce unaceptable overhead.
Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support.
Tags:
----
REL8_2_STABLE
Modified Files:
--------------
pgsql/src/backend/access/gist:
gistget.c (r1.62 -> r1.62.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistget.c?r1=1.62&r2=1.62.2.1)
gistscan.c (r1.65 -> r1.65.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistscan.c?r1=1.65&r2=1.65.2.1)
pgsql/src/include/access:
gist_private.h (r1.24 -> r1.24.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gist_private.h?r1=1.24&r2=1.24.2.1)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Remove tuple's killing by killtuple() if tuple was moved to another
page - it could produce unaceptable overhead.
Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support.
Tags:
----
REL8_3_STABLE
Modified Files:
--------------
pgsql/src/backend/access/gist:
gistget.c (r1.69 -> r1.69.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistget.c?r1=1.69&r2=1.69.2.1)
gistscan.c (r1.68 -> r1.68.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistscan.c?r1=1.68&r2=1.68.2.1)
pgsql/src/include/access:
gist_private.h (r1.28 -> r1.28.2.1)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gist_private.h?r1=1.28&r2=1.28.2.1)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
Remove tuple's killing by killtuple() if tuple was moved to another
page - it could produce unaceptable overhead.
Backpatch up to 8.1 because the bug was introduced by GiST's concurrency support.
Modified Files:
--------------
pgsql/src/backend/access/gist:
gistget.c (r1.74 -> r1.75)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistget.c?r1=1.74&r2=1.75)
gistscan.c (r1.70 -> r1.71)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/gist/gistscan.c?r1=1.70&r2=1.71)
pgsql/src/include/access:
gist_private.h (r1.31 -> r1.32)
(http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/include/access/gist_private.h?r1=1.31&r2=1.32)
--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
>
> Branching the topic, I have a question about this. I haven't studied
> hstore extensively but this seems like a problem on it's face.
> Shouldn't you be able to take the result of a select and pass it back
> to a select? I mean, what happens if you do this?
>
"a"=>"b" is a value of hstore type, so query should be:
select '"a"=>"b"'::hstore;
" character was chosen to simplify escaping,
> I ran into a similar issue with my chkpass type (see contrib) where the
> string inserted into the field is stored encrypted with functions to
> test for equality basically like the Unix password model works. If I
> just displayed raw strings then a dump and reload would have trashed
> all the passwords by re-encrypting them. What I did was to make a
> special case on input. If the string started with ':' then I strip
> that character and insert the string unchanged. Then I changed the
> output to prepend the ':'. Now dump and reload work.
I see, but your problem is that password is one-way encrypted, so, you
definitely need to distinguish already encrypted strings. Hstore hasn't that
problem.
--
Teodor Sigaev E-mail: teodor@sigaev.ru
WWW: http://www.sigaev.ru/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
