Tom Lane skrev:
The money type is considered deprecated. I was also under the impression
it would be eventually removed. Why are we accumulating TODOs for it?
Because doing the TODOs would remove the reasons for deprecating it.
Whether it is actually ever going to disappear is not agreed upon.
ITAGAKI Takahiro skrev:
I guess it works well for % but not for _ , the latter has to know, how
many bytes the current (multibyte) character covers.
Yes, % is not used in trailing bytes for all encodings, but _ is
used in some of them. I think we can use the optimization for all
of the server
On Thu, 4 Sep 2003, Shridhar Daithankar wrote:
> > column? I think MAX() does not know or cares if a column is indexed, but...
>
> No. Postgresql uses MVCC which mean there could be multiple views of sample
> tuple active at the same time. There is no way to tell which is max. value for
> a col
On Fri, 5 Sep 2003, Bruce Momjian wrote:
> > When I was curious as to how COUNT might be maintained, I was pretty
> > sure that this wouldn't be the preferred method...
>
> See my later idea of the trigger doing +/-1 rather than locking the
> value during the transaction.
>
> If we don't do it t
On Tue, 16 Sep 2003, Tom Lane wrote:
> This is not a 100% solution to our problems. I don't think we could use
> it to solve the problem for int2 columns ("int2col = 42") because it'd
> be unsafe to promise that an int4-to-int2 cast could be inserted into
> an expression without changing the beha
On Wed, 17 Sep 2003, Tom Lane wrote:
> Another thing to keep in mind is that it's not always the case that
> assigning the right type to a literal constant would solve the problem.
> We have the same issues with variables; for example, a join with
> "WHERE a.int8col = b.int4col" may fail to take a
Merlin Moncure skrev:
The missing piece of the puzzle is the ability to recover a failed
transaction without issuing a full commit/rollback. This could be a
new flavor of the savepoint command, commit command, or a new command.
As a bonus, upon recovering the transaction you could snap an sql
s
Tom Lane skrev:
Is there any cross-check on the correctness of this list?
As have been said, there is a registration service that makes it harder
to steal nicks.
There is no guarantee that anyone who claim to be this or that really is
who he say he is. On the other hand, a lot of us have b
David Fetter skrev:
As far as big missing features go, here's a short list:
* Windowing functions
If we are to wish for things the window functions and a proper
collation/locale support is what I miss the most.
/Dennis
---(end of broadcast)
Tom Lane skrev:
setseed(dp)
int
- set seed for subsequent random() calls
+ set seed for subsequent random() calls (value
between -1.0 and 1.0)
Looking at the code, it would appear that the intended range is 0 to 1.
Ok.
What about the return value? The doc didn'
On 14 Mar 2005, Greg Stark wrote:
> select distinct on (x) x,y,z
> order by x,y,z
>
> You can do the equivalent:
>
> select x, first(y), first(z)
> order by x,y,z
> group by x
>
> But you can also handle the more general case like:
>
> select x, first(y), first(z), avg(a), sum(s)
> order b
On 14 Mar 2005, Greg Stark wrote:
> > SELECT ROW_NUMBER() OVER bar AS num,
> >x,
> >avg(a) OVER bar,
> >sum (a) OVER bar
> > FROM foo
> > WINDOW bar AS PARTITION BY x ORDER BY x, y, z;
>
> Note that as you said, this returns just as many records as are in the
> original t
On Tue, 5 Apr 2005, Tom Lane wrote:
> CREATE FUNCTION sum_n_product(x int, y int, OUT sum int, OUT prod int) AS $$
> BEGIN
> sum := x + y;
> prod := x * y;
> RETURN;
> END;
> $$ LANGUAGE plpgsql;
>
> The RETURN statement is kinda useless in this example, but it is still
> required, be
On Fri, 15 Apr 2005, ElayaRaja S wrote:
> Hi,
> I am unable to restart the PostgreSQL. I am using redhat Linux 9
> with postgresql 7.4.5. Unexpectedly due to ups problem my server was
> shutdown once. After that i am unable to restart the server.
> DETAIL: The data directory was initialized by
On Sun, 1 May 2005, Alvaro Herrera wrote:
> Well, if process A loses the connection to the client, then the
> transaction will be rolled back and other processes will be able to
> continue.
If the other end of a tcp/ip connection just disapears, for example if the
network cable is cut off then in
On Sun, 1 May 2005 [EMAIL PROTECTED] wrote:
> If a database wants to get bigger on the usage these settings like this
> must be implemented.
Lucky thing that postgresql is open source so you or anyone else that need
it can implement or sponsor it. Postgresql gets as good as we make it and
nothi
On Mon, 2 May 2005, Tom Lane wrote:
> #1 Defend against loss of connectivity to client
>
> I claim that if you have a problem with #1 you ought to go discuss it
> with some TCP hackers: you basically want to second-guess the TCP
> stack's ideas about appropriate timeouts. Maybe you know what yo
On Wed, 4 May 2005, Marc G. Fournier wrote:
> Just curious here ... but do any of the version control systems provide
> "per directory user restrictions"? Where I could give CVS access to
> Joshua, for instance, just to the plphp directory?
Just how many incidents where people change the wrong
On Wed, 4 May 2005, Joshua D. Drake wrote:
> > Just how many incidents where people change the wrong files do you except.
> > Maybe it's just easier to handle one such case every third year than to
> > set up some system to prevent it.
>
> The number of incidents isn't the issue, the fact that
How come we don't set SO_KEEPALIVE in libpq?
Is there any reason why we wouldn't want it on?
--
/Dennis Björklund
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
On Mon, 16 May 2005, Tom Lane wrote:
> > How come we don't set SO_KEEPALIVE in libpq?
> > Is there any reason why we wouldn't want it on?
>
> Is there any reason we *would* want it on? The server-side keepalive
> should be sufficient to get whatever useful impact it might have.
Wouldn't the cl
On Mon, 16 May 2005, Tom Lane wrote:
> On the other hand, it seems to me a client-side SO_KEEPALIVE would only
> be interesting for completely passive clients (perhaps one that sits
> waiting for NOTIFY messages?) A normal client will try to issue some
> kind of database command once in awhile
A
On Tue, 31 May 2005, Tom Lane wrote:
> The case that convinced me we need to keep some sort of backslash
> capability is this: suppose you want to put a string including a tab
> into your database. Try to do it with psql:
> t=> insert into foo values ('
> Guess what: you won't get anywhere,
On Tue, 31 May 2005, Tom Ivar Helbekkmo wrote:
> ...or ^V followed by TAB, as per age-old tradition. :-)
Right, I forgot about that one. One can also do other control characters
instead of TAB by pressing CTRL-J and similar.
Well, I just wanted to point out that it's possible. The main problem
On Wed, 15 Jun 2005, Bruce Momjian wrote:
> > K, that's what confused me as I got the impression it was ok to require
> > LGPL libraries but not GPL.
>
> I think the answer isn't clear on that one.
If that is not clear then what is the difference between a LGPL lib and a
GPL one? To copy code fr
On Wed, 6 Jul 2005, Darren Alcorn wrote:
> I was interested as to if there were plans to develop SQL99 nested
> tables.
Could you give an example of SQL99 nested tables? It might help us who
don't know what the term stand for understand the issue. I've browsed
through (bur not fully read) sql99 m
On Sun, 10 Jul 2005, Sivaraman K.G wrote:
> The error in the log file is as follows :
>
> ERROR : xlog flush request 0/D17B00 is not satisfied ---
> flushed only to
> 0/C31ED0
> CONTEXT : writing block 0 of relation 17231/17232/17249
> WARNING : could not write
On Mon, 1 Aug 2005, Jeff Davis wrote:
> Does the SQL standard provide no way to have a NULL character in a
> string constant? Is single-quote the only special character?
I don't think it forbids you from using the null character. It's not like
the strings are zero terminated. Some encodings migh
On Tue, 2 Aug 2005, Jeff Davis wrote:
> >>Does the SQL standard provide no way to have a NULL character in a
> >>string constant? Is single-quote the only special character?
> >
> > I don't think it forbids you from using the null character. It's not like
> > the strings are zero terminated. Som
On Wed, 10 Aug 2005, elein wrote:
> implementation of the SQL-3 standard for multi-value NULLs
> for PostgreSQL?
SQL-3, that's what became sql99, isn't it?
Anyway, there is nothing like what you explained in sql 99 nor sql 2003.
The boolean type have a third value called UNKNOWN that is just a
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 cl
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 wou
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 swe
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 seq
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 o
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?
--
/Den
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 li
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 tabl
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 t
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 t
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 sever
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 ch
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
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 so
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 sti
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
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 someth
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 conti
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 e
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 tw
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 i
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 table
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'
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 d
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 broadcast)--
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
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
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 si
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
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 mainta
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 be
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 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 rat
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;
--
/Denni
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
subbegi
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:
> > Simon posted it. It is called RELEASE:
>
> We can't actually release anything (commit the subtransactions), because
> they may be savepoints established after that point, and they are
> logically "inside" the previously established ones. At RELEASE
On Fri, 9 Jul 2004, Alvaro Herrera wrote:
> Yes, we free some things. Granted it's not a lot, but we have stacks
> for several things that will be always be growing with savepoints,
They will not always be growing for savepoints, you can free things when
using savepoints just as with subtransac
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 i
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 co
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:
>
> CREAT
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
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) Yo
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 ex
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;
> >
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 \z to display permissions of the object in \d
I think it's time to start with longer command names. Tab completion makes
it easy anyway. The short ones should still be
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
denni
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 migh
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 Björk
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...
>
On Sat, 7 Aug 2004, Takehiko Abe wrote:
It looked like you sent the last mail only to me and not the list. I
assume it was a misstake and I send the reply to both.
> > Is there a specific reason you want to restrict it to 24 bits?
>
> ISO 10646 is said to have removed its private use codepoints
On Sat, 7 Aug 2004, John Hansen wrote:
> Now, is it really 24 bits tho?
> Afaict, it's really 21 (0 - 10 or 0 - xxx1 )
Yes, up to 0x10 should be enough.
The 24 is not really important, this is all about what utf-8 strings to
accept as input. The strings are stored
On Mon, 16 Aug 2004, Tom Lane wrote:
> > in oracle it's
> > WHEN OTHERS THEN null;
> > but this syntax doesn't work in postgres.
>
> It looks like about five minutes' work to add such a thing ... anyone
> have any objections?
Is NULL above an empty statement in oracle or is it a normal expressio
On 17 Aug 2004, Greg Stark wrote:
> With Postgres I effectively have to work in autocommit mode. Starting over
> from scratch every time I make a typo is infeasible. It feels like trying to
> type in a C program using "cat". I've done it before but it's not something I
> want to repeat often.
I a
1 - 100 of 228 matches
Mail list logo
