> "Gregory" == Gregory Stark writes:
>>> I don't believe that the standard forbids the use of combining
>>> chars at all. RFC 3629 says:
>>>
>>> ... This issue is amenable to solutions based on Unicode
>>> Normalization Forms, see [UAX15].
Gregory> This is the relevant part. Tom was
2009/4/14 Josh Berkus :
>
>>> - what if I need to know about operators, operator classes, schemas, etc
>>> etc
>>
>> Fine, let's log this info for those too (or else decide they're too
>> obscure and don't - pg_class and pg_proc are certainly the most
>> interesting cases).
>
> I would suggest put
On Mon, Apr 13, 2009 at 7:06 PM, Tom Lane wrote:
> Josh Berkus writes:
>> I would suggest putting this info in a separate table, pg_change. It
>> would have oid, catalog, user_changed, changed_on. That way we could
>> simply keep the data for all objects which have an OID.
>
> That makes more s
On Mon, Apr 13, 2009 at 7:17 PM, Tom Lane wrote:
> Robert Haas writes:
>> This isn't a very good plan. What we should do is first join the
>> values expression against bar, and then join the resulting rows
>> against foo. The optimizer doesn't want to do that, and I think the
>> reason is becau
- - writes:
>>> The original post seemed to be a contrived attempt to say "you should
>>> use ICU".
>>
>> Indeed. The OP should go read all the previous arguments about ICU
>> in our archives.
>
> Not at all. I just was making a suggestion. You may use any other
> library or implement it yourse
On Mon, Apr 13, 2009 at 07:24:31PM -0400, Tom Lane wrote:
> David Fetter writes:
> > Here's a patch that adds a "Function Type" column to \df while
> > removing the now-redundant \da.
>
> Removing \da altogether was nowhere in the consensus, or even in the
> discussion AFAIR.
It's back.
> Also,
Headline generation uses hlCover to get fragments in text with *all*
query items. In case there is no such fragment, it does not return
anything.
What you are asking will either require returning *maximally* matching
covers or handling it as a separate case.
-Sushant.
On Mon, 2009-04-13 at 20:5
Sushant Sinha writes:
> Headline generation uses hlCover to get fragments in text with *all*
> query items. In case there is no such fragment, it does not return
> anything.
> What you are asking will either require returning *maximally* matching
> covers or handling it as a separate case.
Effic
Sushant Sinha writes:
> Sorry for the delay. Here is the patch with FragmentDelimiter option.
> It requires an extra option in HeadlineParsedText and uses that option
> during generateHeadline.
I did some editing of the documentation for this patch and noticed that
the explanation of the fragmen
Tom Lane wrote:
> Itagaki Takahiro writes:
> > Here is a patch to implement GetPlatformEncoding() and convert absolute
> > file paths from database encoding to platform encoding.
>
> This seems like a fairly significant overhead added to solve a really
> minor problem (if it's not minor why ha
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> Here's a patch that adds a "Function Type" column to \df while
> removing the now-redundant \da.
1. How does it make it redundant - is there a way to view all
aggregates with \df now?
2. Even if the above is satisfied, I think we need a litt
David Fetter writes:
> Here's a patch that adds a "Function Type" column to \df while
> removing the now-redundant \da.
Removing \da altogether was nowhere in the consensus, or even in the
discussion AFAIR. Also, what is the point of using single-letter
type codes when you've made the column hea
Robert Haas writes:
> This isn't a very good plan. What we should do is first join the
> values expression against bar, and then join the resulting rows
> against foo. The optimizer doesn't want to do that, and I think the
> reason is because it knows that the left join might introduce null
> va
Josh Berkus writes:
> I would suggest putting this info in a separate table, pg_change. It
> would have oid, catalog, user_changed, changed_on. That way we could
> simply keep the data for all objects which have an OID.
That makes more sense to me --- it would easily extend to all cases
and w
- what if I need to know about operators, operator classes, schemas, etc
etc
Fine, let's log this info for those too (or else decide they're too
obscure and don't - pg_class and pg_proc are certainly the most
interesting cases).
I would suggest putting this info in a separate table, pg_chan
I have a query that performs poorly which can be simplified to the
following test case (v8.3.6).
CREATE TABLE foo (id integer, primary key (id));
INSERT INTO foo SELECT generate_series(1,10);
CREATE TABLE bar (id integer, foo_id integer not null references foo (id),
PRIMARY KEY (id));
INSERT I
Pavel Stehule writes:
> this my proposal is very simple. It help to people who have to manage
> large or complex database system. Important data are date of creating
> and date of altering tables and stored procedures. These data cannot
> be modified by user, so implementation doesn't need any new
2009/4/13 Kevin Grittner :
> Pavel Stehule wrote:
>> Important data are date of creating and date of altering tables
>> and stored procedures. These data cannot be modified by user, so
>> implementation doesn't need any new statements.
>>
>> Notes, objections?
>
> This feature has been present in
Hi,
I'm getting the following failure on RHEL 4:
http://www.gunduz.org/temp/regression.out
http://www.gunduz.org/temp/regression.diffs
Here is the Makefile.regress that I use while building RPMs on 8.4:
https://projects.commandprompt.com/public/pgcore/repo/rpm/redhat/8.4/postgresql/EL-4/Makefil
Pavel Stehule wrote:
> Important data are date of creating and date of altering tables
> and stored procedures. These data cannot be modified by user, so
> implementation doesn't need any new statements.
>
> Notes, objections?
This feature has been present in other database products I've used,
Tom Lane wrote:
> Greg Stark writes:
>> Is it really true trhat canonical encodings never contain any composed
>> characters in them? I thought there were some glyphs which could only
>> be represented by composed characters.
>
> AFAIK that's not true. However, in my original comment I was think
Tom Lane wrote:
Andrew Dunstan writes:
This isn't about the number of bytes, but about whether or not we should
count characters encoded as two or more combined code points as a single
char or not.
It's really about whether we should support non-canonical encodings.
AFAIK that's a
Greg Stark writes:
> Is it really true trhat canonical encodings never contain any composed
> characters in them? I thought there were some glyphs which could only
> be represented by composed characters.
AFAIK that's not true. However, in my original comment I was thinking
about UTF16 surrogate
On Mon, Apr 13, 2009 at 9:15 PM, Tom Lane wrote:
> Andrew Dunstan writes:
>> This isn't about the number of bytes, but about whether or not we should
>> count characters encoded as two or more combined code points as a single
>> char or not.
>
> It's really about whether we should support non-can
Andrew Dunstan writes:
> This isn't about the number of bytes, but about whether or not we should
> count characters encoded as two or more combined code points as a single
> char or not.
It's really about whether we should support non-canonical encodings.
AFAIK that's a hack to cope with imple
On Mon, Apr 13, 2009 at 1:32 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> this my proposal is very simple. It help to people who have to manage
>> large or complex database system. Important data are date of creating
>> and date of altering tables and stored procedures. These data cannot
>> be
On Mon, Apr 13, 2009 at 2:32 PM, Tom Lane wrote:
> Pavel Stehule writes:
>> this my proposal is very simple. It help to people who have to manage
>> large or complex database system. Important data are date of creating
>> and date of altering tables and stored procedures. These data cannot
>> be
Alvaro Herrera wrote:
- - wrote:
1) Functions like char_length() or length() do NOT return the number
of characters (the manual says they do), instead they return the
number of code points.
I think you have client_encoding misconfigured.
alvherre=# select length('á'::text);
length
Alvaro Herrera wrote:
>> 1) Functions like char_length() or length() do NOT return the
number
>> of characters (the manual says they do), instead they return the
>> number of code points.
>
> I think you have client_encoding misconfigured.
>
> alvherre=# select length('á'::text);
> length
> -
Devrim =?ISO-8859-1?Q?G=DCND=DCZ?= writes:
> I'm getting the following failure on RHEL 4:
> http://www.gunduz.org/temp/regression.out
> http://www.gunduz.org/temp/regression.diffs
This test is checking whether you have working 64-bit-tzdata support.
It seems you don't.
If you built with --with-
- - wrote:
> 1) Functions like char_length() or length() do NOT return the number
> of characters (the manual says they do), instead they return the
> number of code points.
I think you have client_encoding misconfigured.
alvherre=# select length('á'::text);
length
1
(1 fila)
a
Tom Lane wrote:
> Pavel Stehule writes:
>> this my proposal is very simple. It help to people who have to
>> manage large or complex database system. Important data are date of
>> creating and date of altering tables and stored procedures. These
>> data cannot be modified by user, so implementat
Folks,
Here's a patch that adds a "Function Type" column to \df while
removing the now-redundant \da.
Cheers,
David.
--
David Fetter http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david.fet...@gmail.com
Remember to vote!
Consider donat
2009/4/13 Tom Lane :
> Pavel Stehule writes:
>> this my proposal is very simple. It help to people who have to manage
>> large or complex database system. Important data are date of creating
>> and date of altering tables and stored procedures. These data cannot
>> be modified by user, so implemen
Tom Lane wrote:
> "Kevin Grittner" writes:
>> a change to CREATE FUNCTION such that there is an implied SET
>> standard_compliant_strings FROM CURRENT
Hopefully obvious, I meant standard_conforming_strings.
> it seems like a really bad idea.
Then perhaps a note in the PL/pgSQL docs about t
This will deny insert of value that allready exists. Which is ok. But
the second scenerio in which unique constraint refuse operation is, when
u try to update more rows to same value in column with unique constraint.
So i need to use count of affected rows, to deny operation if there are
more
Hello,
this my proposal is very simple. It help to people who have to manage
large or complex database system. Important data are date of creating
and date of altering tables and stored procedures. These data cannot
be modified by user, so implementation doesn't need any new
statements.
Notes, ob
Hi.
While PostgreSQL is a great database, it lacks some fundamental
Unicode support. I want to present some points that have--to my
knowledge--not been addressed so far. In the following text, it is
assumed that the database and client encoding is UTF-8.
1) Functions like char_length() or length
On Mon, Apr 13, 2009 at 12:59 PM, mito wrote:
> I am using rules as layer to save every version of row in shadow table, so i
> cant use unique constraint on column, because of many versions may have same
> value.
Use a partial index.
...Robert
--
Sent via pgsql-hackers mailing list (pgsql-hack
I am using rules as layer to save every version of row in shadow table,
so i cant use unique constraint on column, because of many versions may
have same value.
mito
Jaime Casanova wrote:
On Mon, Apr 13, 2009 at 11:12 AM, mito wrote:
It need to simulate unique constraint on field s_users.ne
On Mon, 2009-04-13 at 14:52 +0900, Fujii Masao wrote:
> if (triggered)
> {
> if (smartMode && nextWALfile exists)
> exit(0)
> else
> {
> delete trigger file
> exit(1)
> }
> }
This looks to be the correct one.
--
Simon Riggs www.2ndQuadrant.com
On Mon, Apr 13, 2009 at 12:12 PM, mito wrote:
> Hi,
> is there any way how to count affected rows by on update rule and use it as
> part of condtions.
>
> Example:
>
>
> CREATE OR REPLACE RULE "_UPDATE" AS ON UPDATE TO "users" DO INSTEAD (
> UPDATE "s_users" SET
> id = new.id,
> login
On Mon, Apr 13, 2009 at 11:12 AM, mito wrote:
>
> It need to simulate unique constraint on field s_users.new_id, so it should
> deny to update multiple rows with same value.
>
> Any suggestions are welcome.
>
why not simply create a UNIQUE constraint?
--
Atentamente,
Jaime Casanova
Soporte y c
Hi,
is there any way how to count affected rows by on update rule and use it
as part of condtions.
Example:
CREATE OR REPLACE RULE "_UPDATE" AS ON UPDATE TO "users" DO INSTEAD (
UPDATE "s_users" SET
id = new.id,
login = new.login,
WHERE id IN (SELECT id FROM "s_users" ) AND
Hi.
Anyhow, I appreciate discussion.
- Original Message -
From: "Tom Lane"
Itagaki Takahiro writes:
Here is a patch to implement GetPlatformEncoding() and convert absolute
file paths from database encoding to platform encoding.
This seems like a fairly significant overhead add
Abhijit Menon-Sen writes:
> [ a test whose purpose he didn't bother to describe ]
What is the value of this? It seems far more likely to cause
maintenance pain than to catch anything interesting.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@p
Itagaki Takahiro writes:
> Here is a patch to implement GetPlatformEncoding() and convert absolute
> file paths from database encoding to platform encoding.
This seems like a fairly significant overhead added to solve a really
minor problem (if it's not minor why has it never come up before?).
I
Hi,
On Mon, Apr 13, 2009 at 7:21 PM, Guillaume Smet
wrote:
> On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao wrote:
>> 1. the trigger file containing "smart" is created.
>> 2. pg_standby is executed.
>> 2-1. nextWALfile is restored.
>> 2-2. the trigger file is deleted because nextWALfile+1 do
On Mon, Apr 13, 2009 at 7:52 AM, Fujii Masao wrote:
> 1. the trigger file containing "smart" is created.
> 2. pg_standby is executed.
>2-1. nextWALfile is restored.
>2-2. the trigger file is deleted because nextWALfile+1 doesn't exist.
> 3. the restored nextWALfile is applied.
> 4. pg_stan
Itagaki Takahiro wrote:
> "Hiroshi Saito" wrote:
>
> > Um, I had a focus in help the problem which is not avoided.
> > I am not sensitive to a problem being avoided depending on usage.
> > However, I will wish to work spontaneously, when it is help much.
>
> I'll research whether encoding
Sorry, I screwed up a little in sending that patch. Here it is again as
an attachment.
-- ams
diff --git a/src/test/regress/sql/defs.sql b/src/test/regress/sql/defs.sql
new file mode 100644
index 000..cf8fff3
--- /dev/null
+++ b/src/test/regress/sql/defs.sql
@@ -0,0 +1,24 @@
+-- Test pg_get_fu
51 matches
Mail list logo
