On Sun, 16 Nov 2003, Tom Lane wrote:
There isn't any compelling implementation reason when to freeze the
value of now(). Reasonable options are
1. at BEGIN (current behavior)
2. at transaction's external creation
3. at freezing of transaction snapshot
#1 and #2 are
I'm in the middle of implementing function parameter names. In pg_proc
the types of the parameters are currently stored as an oidvector, but
how should I store the parameter names?
Would it be a good idea to create a namevector in the same way as
oidvector? Would a normal array like name[] be
On Sun, 23 Nov 2003, Peter Eisentraut wrote:
How will that work in arbitrary procedural languages?
It is passed along to the handler of the language, and if the language
wants, it can insert these into its environment before execution. I plan
to look at the languages pgsql and sql, but any
On Sun, 23 Nov 2003, Tom Lane wrote:
Actually I'd suggest text[], as there is no good reason to pad the
array entries to a fixed length.
The only reason against is that all other identifiers have this arbitrary
limit. But sure, text[] would work just as well and without any
restriction.
Is
On Mon, 24 Nov 2003, Christopher Kings-Lynne wrote:
Is there demand for this syntax:
ALTER SEQUENCE ON table(col) CYCLE 100;
It would allow us to become sequence-name independent...
The above is an operation that would not help me a lot, but a way of
performing currval() without knowing
On Mon, 24 Nov 2003, Peter Eisentraut wrote:
1. Take out the character set conversion routines from the backend and
make them a library of their own. This could possibly be modelled after
iconv, but not necessarily. Or we might conclude that we can just use
iconv in the first place.
2.
On Tue, 25 Nov 2003, Peter Eisentraut wrote:
Force all translations to be in unicode and convert to other client
encodings if needed. There is no need to support translations stored using
different encodings.
Tell that to the Japanese.
I've always thought unicode was enough to even
On Tue, 25 Nov 2003, Tatsuo Ishii wrote:
I'm tired of telling that Unicode is not that perfect. Another gottcha
with Unicode is the UTF-8 encoding (currently we use) consumes 3
bytes for each Kanji character, while other encodings consume only 2
bytes. IMO 3/2 storage ratio could not be
On Tue, 25 Nov 2003, Tatsuo Ishii wrote:
I'm tired of telling that Unicode is not that perfect. Another gottcha
with Unicode is the UTF-8 encoding (currently we use) consumes 3
bytes for each Kanji character, while other encodings consume only 2
bytes. IMO 3/2 storage ratio could not be
On Sun, 23 Nov 2003, Tom Lane wrote:
Actually I'd suggest text[], as there is no good reason to pad the
array entries to a fixed length.
I've implemented this part now and it stores the paremeter names in the
pg_proc table as a text[] field.
However, in the parser I use IDENT to get the
On Tue, 25 Nov 2003, Tom Lane wrote:
Dennis Bjorklund [EMAIL PROTECTED] writes:
However, in the parser I use IDENT to get the parameter names and already
in the lexer the IDENT tokens are truncated to length NAMEDATALEN.
Right. What's the problem?
It's strange to allow identifiers
On Sat, 13 Dec 2003, Christopher Browne wrote:
Unfortunately, this doesn't seem to fit with the way WITH is defined
in SQL.
How is the WITH construct defined in SQL?
--
/Dennis
---(end of broadcast)---
TIP 7: don't forget to increase your
The 14 december I submitted a patch that implements named function
arguments. So far no one have said anything about that. It would be nice
if someone could look at it and either reject, accept, put on queue, or
anything else.
The patch is very big (400k), but most of that size comes from trival
On Sun, 21 Dec 2003, Bruce Momjian wrote:
Uh, I don't remember seeing your patch, and I don't have it in my
mailbox? Which email list did you send it to? Perhaps the email is
stuck waiting for Marc to accept it.
http://archives.postgresql.org/pgsql-patches/2003-12/msg00176.php
--
/Dennis
On Sun, 11 Jan 2004, Peter Eisentraut wrote:
Another problem with pushing psql's queries into the backend is that
much of the output that psql makes is not a single table. Sometimes
there is more than one table, or the information is in the table
footers.
Yes, pushing the \xx commands
How come --enable-nls in configure is not turned on as default? I don't
think I can name any other program where it's not.
--
/Dennis Björklund
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
On Wed, 21 Jan 2004, Christopher Kings-Lynne wrote:
This seems to be reproducible...
Here is a smaller example that show the problem:
CREATE TABLE foo (a INT);
BEGIN;
ALTER TABLE foo SET WITHOUT OIDS;
INSERT INTO foo values (5);
ROLLBACK;
VACUUM FULL foo;
It's easy to guess what is
On Wed, 21 Jan 2004, Michael Brusser wrote:
So 'rows' values are incorrect.
You can increase the statistics-gathering for that column with ALTER TABLE
and probably get better estimates.
Also looking at queries with 'KnowledgeBase'
and 'OtherParam' - does seq. scan make sense?
I mean
On Sat, 24 Jan 2004, Peter Eisentraut wrote:
Dennis Bjorklund wrote:
One advantage of this is that you can do cvs diff foo.patch and
get a patch file without a lot of garbage.
Maybe you would be happier if you build outside the source tree. Do
Sure, one can do that.
Still
I've been looking (and coded) a little bit on named function calls. Calls
on the form:
foo (x = 13, y = 42)
Implementing this means that the symbol = no longer can be defined by the
user as an operator. It's not used as default in pg, but I just want to
tell you up front in case you don't
On 25 Jan 2004, Greg Stark wrote:
foo (x = 13, y = 42)
Is it really necessary to steal it?
Yes, it is necessary since the arguments to a function are just
expressions. If you do not the above would be ambigious and there is no
clean way to fix that. Say that = is an operator
On Sun, 25 Jan 2004, elein wrote:
Barring any override from the SQL200x standard,
I would strongly suggest AS, too.
I kind of like AS also now after thinking about it. The only reason for =
is that oracle used it, nothing else.
As I wrote in another mail, I will check out sql200x.
foo
I've been looking in the sql200x draft and there are no function calls
with named arguments.
Thinking more about it, I'm not sure if it really is an important addition
at all. I've got a number of requests for the feature. so there are people
that want it, that much I know.
I don't think it's
On Tue, 27 Jan 2004, Tom Lane wrote:
In particular, how will you avoid individually trawling through every
function with a matching name to try to match up the arguments?
I don't think you can avoid that. But it's just done once to find the oid
of the real function, so if it's used multiple
On Tue, 27 Jan 2004, Peter Eisentraut wrote:
just a question of what syntax to use. Personally, I would be OK with
=.
That's also what I'm leaning towards now. As Greg suggested, just making
= a special case as a function parameter. And if one want's to call a
function with an expression
On Tue, 27 Jan 2004, Tom Lane wrote:
speed hits in parsing them, especially not if the hit occurs whether
one uses the named-parameters feature or not ...
I'll read the rest of the mail more careful tomorrow moring, I just want
to point out directly that for calls that doesn't use named
On Tue, 27 Jan 2004, Tom Lane wrote:
each candidate. func_select_candidate depends on having some notion of
the same argument position, but what does that mean in such a case?
While it is true that I don't know everything about the current code I
still claim that it can not be such a big
On Wed, 28 Jan 2004, Tom Lane wrote:
when the programmer simply adds names to the parameter declarations
of a function without changing any call sites. If the presence of
parameter names changes the ambiguity resolution rules at all, I'm
doubtful that we could guarantee not to break things.
When I try to commit to cvs it gets stuck and outputs this messages every
30:th second:
cvs server: [11:11:28] waiting for ishii's lock in
/cvsroot/pgsql-server/src/bin/pg_controldata/po
--
/Dennis Björklund
---(end of broadcast)---
TIP 9: the
The IN and ANY constructs works with different kinds of collections to the
right. This is the current situation:
SUB QUERY VALUE LIST ARRAY
IN X X
ANY X X
The SQL standard specifies that = ANY should be equivalent to IN
On Tue, 2 Mar 2004, Joe Conway wrote:
regression=# select 1 where array[1] in (array[1]);
?column?
--
1
(1 row)
regression=# select 1 where array[1] in (array[1,2]);
?column?
--
(0 rows)
The only reason I brought it up was that to me ANY and IN are pretty
On Thu, 4 Mar 2004, Fabien COELHO wrote:
(1) Do postgresql Masters think this issue is worth being pursued, or
any patch will be rejected as it is considered intrinsicly useless?
While I can't speak for others I would anyhow guess that everyone wants
better error messages. I know I want
When UNSAFE_FLOATS is defined there is a check that float results are
within the min and max limits, which excludes values like 'Infinity',
'-Infinity' and 'Nan'.
Is the above something from the SQL standard or just a bug?
The input rules for float8 accepts 'Infinity' as a value, and then it
On Wed, 10 Mar 2004, Neil Conway wrote:
No, 'NaN' is legal float4/float8/numeric input whether UNSAFE_FLOATS
is defined or not.
Yes, the tests are:
if (fabs(val) FLOAT8_MAX)
if (val != 0.0 fabs(val) FLOAT8_MIN)
and only infinity and not NaN will trigger the overflow. I read it wrong
On Thu, 11 Mar 2004, Neil Conway wrote:
So, what is the correct behavior: if you multiply two values and get a
result that exceeds the range of a float8, should you get
'Infinity'/'-Infinity', or an overflow error?
That's the issue and I think we should allow infinity as a result of a
float
On Thu, 11 Mar 2004, Neil Conway wrote:
Fair enough. Attached is a patch that implements this. I chose to
remove UNSAFE_FLOATS: if anyone thinks that is worth keeping, speak up
now.
I have one question about the use of HUGE_VAL in postgresql. I got the
impression that the whole thing was
This testcase works in 7.3 but not in 7.4:
--
create table t1 (a int);
create table t2 (b int);
select * from t1, (select b as a from t2 group by a) as foo;
--
ERROR: column t2.b must appear in the GROUP BY
On Mon, 5 Apr 2004, Tom Lane wrote:
This example strikes me as a good reason why we ought to deprecate and
eventually remove the capability for GROUP BY to reference output-list
aliases. This is not legal per SQL spec,
Sticking to the SQL spec is (almost) always good.
matches. This would
In 7.4 there is an optional BY that are allowed in the definiton of
sequences:
CREATE [ TEMPORARY | TEMP ] SEQUENCE namn [ INCREMENT [ BY ] ökning ]
[ MINVALUE minvärde | NO MINVALUE ] [ MAXVALUE maxvärde | NO MAXVALUE ]
[ START [ WITH ] start ] [ CACHE cache ] [ [ NO ] CYCLE ]
(some
On Wed, 7 Apr 2004, Dennis Bjorklund wrote:
Replying to myself here :-)
wants to import it into a 7.3 database. Use the 7.3 dump you might say,
but since BY does not do anything why not remove it from the dump output?
I just realized there is yet another new construct in 7.4. The sequences
On Wed, 7 Apr 2004, Peter Eisentraut wrote:
=? as != is a synonum for , it would make sense.
That was never such a terribly good idea, IMHO.
Agreed. Compilers should give errors and not try to work around bad code.
Had the first generation of browsers done that we would have had a much
On Wed, 7 Apr 2004, Fabien COELHO wrote:
Is it bad code? Not for people who come from a C/C++/Java background.
It's not the sql operator.
Every week I meet MySql people that want to port their application to
another database and run into problems because they use some mysql
construct instead
On Wed, 7 Apr 2004, Fabien COELHO wrote:
From my point of view, my students come from a java first course, so they
have to learn again some new syntax and new operators. Small stuff, but
it can help to say same as java and go on to new concepts.
Don't you want them to learn SQL?
--
/Dennis
Is anyone working to make the locale support in pg better? Running initdb
to set the locale is a bit heavy. It would be nice to at least be able to
set it per database.
--
/Dennis Björklund
---(end of broadcast)---
TIP 6: Have you searched our
On Wed, 7 Apr 2004, Tom Lane wrote:
And even more to the point, it would corrupt non-shared indexes
inherited from template1. This could not be finessed --- AFAICS you'd
need to do the equivalent of a REINDEX in the new database to make it
work.
From what I can tell there is only 3 tables
On Wed, 7 Apr 2004, Tom Lane wrote:
If that were so, we'd not have a problem. The reason we have to tread
very carefully is that we do not know what tables/indexes users might
have added to template1.
Aah, now I see the real problem!
If we copy a text index into a new database and claim
On Wed, 7 Apr 2004, Tom Lane wrote:
solution, which is per-column locale settings within databases.
Of course, but that solution might be many years ahead.
Peter E. seems to think that it's not an infeasible amount of work.
(See previous discussion that he mentioned earlier in this
On Thu, 8 Apr 2004, Tatsuo Ishii wrote:
Are you talking about the sort order? Then there's no problem with
encoding itself.
The tables in template1 in encoding E1 are compied into the new database
in encoding E2. Not all encodings are compatable, so you can't even
convert from E1 to E2.
--
On Thu, 8 Apr 2004, Tatsuo Ishii wrote:
The tables in template1 in encoding E1 are compied into the new database
in encoding E2. Not all encodings are compatable, so you can't even
convert from E1 to E2.
In this case you just set your terminal encoding to E1, then SELECT
the table.
On Thu, 8 Apr 2004 [EMAIL PROTECTED] wrote:
more flexable configuration based on the idea that configuration and data
are in SEPARATE locations is important.
Why is it important and wouldn't it just make it harder to have several
database clusters (for example with different locale) or
On Thu, 8 Apr 2004, Tom Lane wrote:
See my previous point: the index does not actually fail, in our current
implementation, because strcoll() is unaffected by the database's
encoding setting.
How can it be? If I have a utf-8 template1 and a table with an index
sorted according to the utf-8
On Thu, 8 Apr 2004, Tom Lane wrote:
No, the ordering *will* be the same as it was before, because strcoll()
is still functioning the same. You'd get the same answer from a sort
operation since it depends on the same operators.
It interprets them according to LC_CTYPE, which does not
On Thu, 8 Apr 2004, Tom Lane wrote:
You're missing the point: strcoll() is not going to compare them as
latin1 strings. It's going to interpret the bytes as utf-8 strings,
because that's what LC_CTYPE will tell it to do.
My current understanding of what you are saying now is that LC_CTYPE is
On Thu, 8 Apr 2004, Tom Lane wrote:
Yup, exactly. If we did not force both LC_COLLATE and LC_CTYPE to have
the same values cluster-wide, then we *would* have index corruption
issues.
We really show warn people that using another encoding in a database then
what the cluster uses, breaks
For my own amusement I'm reading the sql 92 spec about character sets.
There are some concepts that are a bit difficult that maybe someone can
explain for me:
character set
character repertoire
for example in 4.2.1 it says:
A character set is described by a character set descriptor. A
I've spent some more time reading specs today. Together with Peter E's
explanataion (Thanks!) I think I've got a farily good understanding of the
parts talking about locales now.
My next question is about lexing. The spec says that one can use strings
of different charsets in the queries, like:
On Tue, 13 Apr 2004, Tom Lane wrote:
We could possibly do it if we restrict to ASCII-superset character sets
(not UTF-16 for instance), so that the string quoting boundaries can be
found without hardwired knowledge about every character set.
It's a reasonable compromise I guess. One can still
On Wed, 14 Apr 2004, Fabien COELHO wrote:
... WHERE field1 = _latin1'FooBar' and field2 = _utf8'Åäö'
different charsets or this is not going to work very well.
What editor or terminal is supposed to be able to generate text in
different encodings depending on the part of the sentence?
On Wed, 14 Apr 2004, Fabien COELHO wrote:
printf(SELECT * FROM foo WHERE field1 = '%s',
latin1_to_database_encoding(...));
And how do you do this if the database encoding is latin2? You can not
convert latin1 to latin2.
The specification was written like this to handle things like
On Fri, 23 Apr 2004, Shachar Shemesh wrote:
When I ask about non-standard complience of Pg (turning unquoted
identifiers to lowercase instead of uppercase, violating the SQL
standard, and requring an expensive rewrite of clients), and I get the
answer uppercase is ugly, I think something
On Sat, 24 Apr 2004, Tom Lane wrote:
Upper-case-only sucks, by every known measure of readability, and I
don't want to have to put up with a database that forces that
1960s-vintage-hardware mindset on me.
Well, get used to it :-)
So what I'm holding out for is a design that lets me continue
On Sat, 24 Apr 2004, Tom Lane wrote:
First I thought that one can store the string with case all the time, and
just convert when needed (when comparing identifiers).
People keep suggesting these random not-quite-standard behaviors, but
I fail to see the point. Are you arguing for exact
On Sun, 25 Apr 2004, Andrew Dunstan wrote:
Why do you want two names? Just keep the original casing, and a boolean
saying if it's quoted or not.
Sorry - brain malfunction - yes, original casing plus boolean would
work. In effect you could derive the canonical form from those two.
Say
On Mon, 26 Apr 2004, Andrew Dunstan wrote:
Ideas still swirling a bit
Sure, I'm thinking in public as well. Not something you want to do if you
are afraid of being wrong and showing it :-) But I'm not.
The constraint would in effect be on CASE WHEN quoted THEN name ELSE upper
(name) END.
On Mon, 24 May 2004, Tom Lane wrote:
I think the cure would probably be worse than the disease. To make any
serious attempt at preventing remove-the-last-superuser, we'd have to
make operations on pg_shadow grab exclusive lock. For instance, you
couldn't allow two backends to DROP USER in
On Wed, 26 May 2004, Tom Lane wrote:
if you have to do an UPDATE that affects every row of a large table
UPDATE tab SET col = col + 1
which leaves you with N live rows, N dead rows, and lots of pain to get
back down to a less-than-twice-normal-size table. (Traditional way is
On Thu, 26 Feb 2004, Gavin Sherry wrote:
Comments? Questions? Suggestions?
Is that plan that in the future one can split a single table into
different table spaces? Like storing all rows with year 1999 in one
tablespace and the rest in another?
With the rule system and two underlying tables
On Tue, 15 Jun 2004, Tom Lane wrote:
I wonder though, do the requestors actually know what they're asking for?
Are they really asking for encoding changes, or are they asking for
locale changes?
Most people don't know exactly what they want.
A lot of people use SQL_ASCII databases and don't
On Sat, 26 Jun 2004, Alvaro Herrera wrote:
(This is suspiciously similar to SAVEPOINTs). Another nice idea would
be to be able to name subtransactions and rollback to a name, which
would bring savepoints even nearer.
Sounds exactly like savepoints. What is the difference and why don't we do
On Mon, 28 Jun 2004, Satoshi Nagayasu wrote:
If I set statement_timeout to 1000 to detect a lock timeout,
I can't run a query which takes over 1 sec.
If a lock wait is occured, I want to detect it immediately,
but I still want to run a long-running query.
Why is it important what it is
On Tue, 29 Jun 2004, Tom Lane wrote:
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index foo_pkey for table
foo
is conveying any useful information?
Maybe there should be another level called NOVICE :-)
--
/Dennis Björklund
---(end of
On Thu, 1 Jul 2004, Justin Clift wrote:
but we found it useful. It adds the column comments to the
information_schema.columns view.
Doesn't the specification say exactly what columns should exist?
Lots of things in the old system tables are not visible in the
information_schema because of
On Thu, 1 Jul 2004, Justin Clift wrote:
Not sure if this is a known issue or not, but I think I may have found a
bug with the way view definitions are shown... at least in psql.
Using 7.5 development CVS (as of a few hours ago) or even 7.4.3, if I
connect using it's version of psql to a
On Thu, 1 Jul 2004, Dennis Bjorklund wrote:
\d information_schema.constraint_column_usage
The thing that does not work is that the SELECT to the left of the UNION
ALL needs to be put inside (), then it works and the parser can parse it.
Looking at the doc page it looks like the () should
On Thu, 1 Jul 2004, Bruno Wolff III wrote:
If DISTINCT ON or LIMIT was used in inner select, then the ORDER BY would
be relevant; so you can't just blindly remove ORDER BY when it is part of
a union.
Of course, but in this case with this view there wasn't any such. It can
still be usable
On Thu, 1 Jul 2004 [EMAIL PROTECTED] wrote:
We're advertising to do pure ANSI, so we'd mislead people if we
supplied non-standard columns.
Yes, but if folks wanted to stick to the standard PostgreSQL would
still work. The only difference is that people who aren't concerned
about being
On Sat, 3 Jul 2004, Andreas Pflug wrote:
IMHO we should rethink if we could make those people happy. How about a
loadable personality (IIRC SAPDB has something like that), to exchange
the parser in use with a custom one (by a SET command)?
Having two parsers would be a nightmare to
On Mon, 5 Jul 2004, Alvaro Herrera wrote:
begin/end because they are already in an explicit/implicit transaction
by default... How is the user/programmer to know when this is the case?
I'm not sure I understand you. Of course you can issue begin/end. What
you can't do is issue
On Tue, 6 Jul 2004, Alvaro Herrera wrote:
We can later implement savepoints, which will have SAVEPOINT foo and
ROLLBACK TO foo as interface. (Note that a subtransaction is slightly
different from a savepoint, so we can't use ROLLBACK TO foo in
subtransactions because that has a different
On Wed, 7 Jul 2004, Oliver Jowett wrote:
Savepoint ROLLBACK TO foo doesn't invalidate 'foo'. If SAVEPOINT foo
is 'start new subtransaction foo', ROLLBACK TO foo must be 'roll back
subtransaction foo and all children; start new subtransaction foo'.
If that is all there is, I much rather see
On Wed, 7 Jul 2004, Oliver Jowett wrote:
So how do you propose supporting simple rollback of a subtransaction? It
seems like an extension regardless of how it's done.
If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
foo; followed by a RELEASE SAVEPOINT foo;
--
/Dennis
On Wed, 7 Jul 2004, Oliver Jowett wrote:
If I understand you correctly what you want is a ROLLBACK TO SAVEPOINT
foo; followed by a RELEASE SAVEPOINT foo;
Ugh.. nasty syntax and an extra empty transaction.
If you translate it directly using only the primitives of the current
On Fri, 9 Jul 2004, Bruce Momjian wrote:
I think we agreed on BEGIN NESTED/COMMIT NESTED, and START NESTED
TRANSACTION and COMMIT NESTED TRANSACTION.
Should I read this as pg will get its own implementation of sub
transactions and not implement the almost equivalent standard (sql99)
savepoint
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
Clearly savepoints do not allow for a snapshot to be released; nested
xacts do.
Why not?
OTOH savepoints are trivial to implement once nested xacts are in place.
They are only syntactic sugar.
Not only, but simple yes. I'm just opposed to having
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
I mean this:
begin;
... work ...;
savepoint foo;
... more work ...;
savepoint bar;
... yet more ... ;
release foo;
At this time I can't release savepoint foo because the implementation
(nested) requires me to keep it open as
On Fri, 9 Jul 2004, Mike Rylander wrote:
Nested transactions and savepoints serve two different purposes. They have
some overlap, but for the most part solve two distinct problems.
Then show some examples that illustrait the difference. So far all
examples shown that uses subtransactions
On Sat, 10 Jul 2004, Gavin Sherry wrote:
3) The savepoint identified by S and all savepoints established in the
current savepoint level subsequent to the establishment of S are
destroyed.
So the standard savepoints are even more like the subtransactions that
alvaro have implemented then I
On Sat, 10 Jul 2004, Mike Rylander wrote:
They do, if only to make particular constructs easier to write. This is an
opinion, but for example an EXCEPTION framework for plpgsql would be easier
to implement and use if it used the nested transactions rather than
savepoint syntax:
CREATE
On Sat, 10 Jul 2004, Tom Lane wrote:
Nonsense. Invalidating an older savepoint must invalidate everything
after it as well. The fact that the savepoint syntax allows you to
express conceptually-ridiculous operations (like that one) is not a
point in its favor IMHO.
Luckily the standard was
On Sat, 10 Jul 2004, Alvaro Herrera wrote:
That's why it's absurd. Why allow an operation which isn't really an
operation?
Same reason why you allow an addition with 0. One can say that it's
not really an operation either.
One can have many different semantics, here are 3 versions:
1) You
On Sat, 10 Jul 2004, Josh Berkus wrote:
In other words:
SAVEPOINT == BEGIN NESTED
RELEASE SAVEPOINT == COMMIT NESTED
ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
Here it should be:
ROLLBACK TO SAVEPOINT == ROLLBACK NESTED; SAVEPOINT;
And just to clearify, this is an
On Sat, 10 Jul 2004, Bruce Momjian wrote:
SAVEPOINT == BEGIN NESTED
RELEASE SAVEPOINT == COMMIT NESTED
ROLLBACK TO SAVEPOINT == ROLLBACK NESTED
Here it should be:
ROLLBACK TO SAVEPOINT == ROLLBACK NESTED; SAVEPOINT;
And just to
On Sat, 10 Jul 2004, Bruce Momjian wrote:
Oracle can use SAVEPOINTS all the time because it knows it is always in
a transaction, but PostgreSQL is not always.
PostgreSQL is also alsways in a transaction. If some use autocommit and go
SAVEPOINT foo;
RELEASE foo;
The first will work and
On Thu, 15 Jul 2004, Alvaro Herrera wrote:
IMHO the \dn+ output would get too wide if you do that. I'd be in favor
of using \zletter to display permissions of the object in \dletter
I think it's time to start with longer command names. Tab completion makes
it easy anyway. The short ones
Why do we have both the type text and type varchar (without limit)?
Couldn't we make one to be an alias for the other?
Since it's 2 distinct types there are some strange effects:
dennis= SELECT CAST ('123'::varchar AS integer);
ERROR: cannot cast type character varying to integer
On Fri, 23 Jul 2004, Gaetano Mendola wrote:
empdb=# explain analyze select * from v_past_connections where login_time
'2004-07-21';
QUERY PLAN
On Sat, 7 Aug 2004, Tom Lane wrote:
shy of a load --- for instance I see that pg_utf_mblen thinks there are
no UTF8 codes longer than 3 bytes whereas your code goes to 4. I'm not
an expert on this stuff, so I don't know what the UTF8 spec actually
says. But I do think you are fixing the
On Sat, 7 Aug 2004, Tom Lane wrote:
question at hand is whether we can support 32-bit characters or not ---
and if not, what's the next bug to fix?
True, and that's hard to just give an answer to. One could do some simple
testing, make sure regexps work and then treat anything else that might
On Sat, 7 Aug 2004, John Hansen wrote:
should not allow them to be stored, since there might me someone using
the high ranges for a private character set, which could very well be
included in the specification some day.
There are areas reserved for private character sets.
--
/Dennis
On Sat, 7 Aug 2004, Tatsuo Ishii wrote:
More seriously, Unicode is filled with tons of confusion and
inconsistency IMO. Remember that once Unicode adovocates said that the
merit of Unicode was it only requires 16-bit width. Now they say they
need surrogate pairs and 32-bit width chars...
1 - 100 of 221 matches
Mail list logo
