Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve this, the following three requirements should be fulfilled:
1. The statement parser should be able to handle this:
create table x (
id serial(N),
...
);
and
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
I can't see this item on the TODO list at all. Where exactly did you
find it?
That's why I wanted it ADDed... ;-)
Best
Peter Eisentraut írta:
Josh Berkus wrote:
I believe that our SERIAL/SEQUENCE stuff is already in compliance
with the SQL standard for sequences (in SQL03). Why would we change
it?
Because your belief is wrong, but Zoltan's proposal is not getting is
closer.
OK, what does the
OK, I admit I haven't read the SQL standards on this matter.
Tino Wildenhain írta:
Am Samstag, den 03.12.2005, 22:23 +0100 schrieb Zoltan Boszormenyi:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve
Jan Wieck írta:
On 12/3/2005 4:23 PM, Zoltan Boszormenyi wrote:
Hi!
I would like to add an entry to PostgreSQL 8.2 TODO:
- Extend SERIAL to a full-featured auto-incrementer type.
To achieve this, the following three requirements should be fulfilled:
1. The statement parser should be able
Jan Wieck írta:
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
value, a minimum value,
and a cycle option. ...
The exact properties of a sequence. It would
Jan Wieck írta:
On 12/5/2005 1:03 PM, Zoltan Boszormenyi wrote:
Jan Wieck írta:
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
value, a minimum value
Hi,
Zoltan Boszormenyi írta:
Jan Wieck írta:
On 12/5/2005 1:03 PM, Zoltan Boszormenyi wrote:
Jan Wieck írta:
On 12/4/2005 5:10 PM, Zoltan Boszormenyi wrote:
I found this in the SQL2003 draft:
4.14.7 Identity columns
... An identity column has a start value, an increment, a maximum
Hi,
I am trying to prove whether PostgreSQL is faster than Informix
so I can feed the management with numbers.
In our system, there is an invoice browser view, an UNION of 12
different tables. (Yes, there are 12 different invoices, like new or
second-hand cars, warranty, service, etc, with
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
$ time echo select * from v_invoice_browse where code||inv_no =
'CARO20020' | dbaccess db
Is there a way to speed this operation up?
Make an expression index on code||inv_no, if you think this case
Gavin Sherry írta:
On Thu, 15 Dec 2005, Gavin Sherry wrote:
On Wed, 14 Dec 2005, Zoltan Boszormenyi wrote:
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
$ time echo select * from v_invoice_browse where code||inv_no =
'CARO20020' | dbaccess db
Jim C. Nasby írta:
Those queries aren't the same though. The view is equivalent to
SELECT *
FROM
(select 'AAA' AS prefix,id from table 1
union select 'AAA',id from table 2
) view
WHERE prefix||id = '...'
In this case the prefixes have already been unioned together, so there's
no
Hi!
Tom Lane írta:
Jim C. Nasby [EMAIL PROTECTED] writes:
I've been able to verify this on 8.1.4; psql -A -t -c 'SELECT * FROM
largetable' /dev/null results in psql consuming vast quantities of
memory. Why is this?
Is it different without the -A?
I'm reading this as just another
Andrew Dunstan írta:
Mark Woodward wrote:
Jim C. Nasby [EMAIL PROTECTED] writes:
On Mon, Jun 05, 2006 at 11:27:30AM -0400, Tom Lane wrote:
I'm reading this as just another uninformed complaint about libpq's
habit of buffering the whole query result. It's possible that
there's
a
Hi,
I just saw these in the TODO list:
o %Disallow changing DEFAULT expression of a SERIAL column?
This should be done only if the existing SERIAL problems cannot be
fixed.
o %Disallow ALTER SEQUENCE changes for SERIAL sequences
because pg_dump does not dump the changes
What are the
Hi,
after some experimentation, I came up with the attached patch,
which implements parsing the following SERIAL types:
SERIAL
SERIAL GENERATED { ALWAYS | BY DEFAULT }
SERIAL GENERATED [ ALWAYS | BY DEFAULT ] AS IDENTITY( sequence options )
The underlying type is still int4 or int8,
so the
Rod Taylor írta:
The condition (column-is_serial column-force_default)
can help enforcing GENERATED ALWAYS at INSERT time
and can also help fixing the two TODO entries about SERIAL.
You will need to include the insert components of the spec which allow
for overriding GENERATED ALWAYS
Hi,
Jim C. Nasby írta:
On Mon, Jun 12, 2006 at 02:27:31PM +0200, B?sz?rm?nyi Zolt?n wrote:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
after some experimentation, I came up with the attached patch,
which implements parsing the following SERIAL types:
As has been pointed
Hi,
Bruce Momjian írta:
There are roughly three weeks left until the feature freeze on August 1.
If people are working on items, they should be announced before August
1, and the patches submitted by August 1. If the patch is large, it
should be discussed now and an intermediate patch posted
Hi,
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
I am working on adding a new column contraint,
namely the GENERATED [ALWAYS | BY DEFAULT ] AS
[ IDENTITY ( sequence_options ) | ( expression )]
Doesn't this still have the issue that we're taking over spec-defined
syntax
Hi,
I have progressed a bit with my pet project, a.k.a $SUBJECT.
Now GENERATED ALWAYS AS IDENTITY and
GENERATED ALWAYS AS ( expr ) work as
intended. Documentation was also extended.
Some test cases are also included, that shows
that ALTER TABLE ALTER TYPE keeps both
the sequence and the
Rod Taylor írta:
On Tue, 2006-08-01 at 18:10 +0200, Zoltan Boszormenyi wrote:
Hi,
I have progressed a bit with my pet project, a.k.a $SUBJECT.
Now GENERATED ALWAYS AS IDENTITY and
GENERATED ALWAYS AS ( expr ) work as
intended. Documentation was also extended.
I'm only commenting
Rod Taylor írta:
For db restoration (pg_dump), how do you restore to the same values as
previously if it is always regenerated? By making ALWAYS a suggestion
for some users instead of always enforced and providing an override
mechanism for it. I assume it only works for relation owners but I've
and ALTER tab RENAME col TO newcol should be easy.
With the introduced infrastructure to correctly support
the first two changes (new column attribute: attidentity)
it is be easy to implement checks to disallow
ALTER TABLE tab DROP DEFAULT on IDENTITY columns.
Best regards,
Zoltán Böszörményi
Zoltan
Tom Lane írta:
[ cc list trimmed to something reasonable ]
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
Hi,
Bruce Momjian írta:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said now, but I don't
Zoltan Boszormenyi írta:
Hi,
Bruce Momjian írta:
Alvaro Herrera wrote:
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
I think Alvaro is saying we need it in a few days, not longer.
I thought he was saying today ;-)
He actually said
Alvaro Herrera írta:
Zoltan Boszormenyi wrote:
OK, here's my current version. The reference leak is fixed.
But as my testcase shows, it only works for single selects
currently. The parser accepts it but COPY doesn't produce
the expected output. Please, suggest a solution.
I'm
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
How about the callback solution for the SELECT case
that was copied from the original? Should I consider
open-coding in copy.c what ExecutorRun() does
to avoid the callback?
Adding a DestReceiver type is a good solution
Zoltan Boszormenyi írta:
The option parsing and error checking is now common.
I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:
ERROR: could not open relation 1663/16384/16723: No such file or
directory
What else
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
The option parsing and error checking is now common.
I also changed it to use transformStmt() in analyze.c.
However, both the UNION and sunselect cases give me
something like this:
ERROR: could not open relation 1663/16384/16723: No such file
Hi,
Böszörményi Zoltán írta:
Böszörményi Zoltán [EMAIL PROTECTED] writes:
With PostgreSQL 8.1.4, I used this:
begin;
select ... into temp myquery1;
copy myquery1 to stdout csv delimiter '|';
rollback;
The performance of this would doubtless vary a lot with the temp_buffers
Bruce Momjian írta:
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
Thanks. Would you please add this instead?
psql
Thanks!!!
Tom Lane írta:
=?iso-8859-2?Q?B=F6sz=F6rm=E9nyi_Zolt=E1n?= [EMAIL PROTECTED] writes:
as per your suggestion, the COPY view TO support was cut and
a hint was added. Please, review.
Committed after some refactoring to avoid code duplication.
Unfortunately, in a moment of
Hi,
we came across a database where a table had a toasted table,
keeping huge amounts of disk space allocated. However,
the table's current definition didn't explain why there was
a toasted table. Then upon some experiments, it struck me.
There _was_ a toasted field but as the schema was
Hi,
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
So, I should allow DROP DEFAULT, implement
SET DEFAULT GENERATED ALWAYS AS
and modify the catalog so the GENERATED property
is part of pg_attrdef.
Sounds good
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Apart from making the patch a bit smaller again, checking only
for 'i' still allows multiple SERIALs in the same table but lets
disallowing multiple GENERATED ALWAYS AS IDENTITY.
Thinking a bit about it, is it desired to disallow
Andrew Dunstan írta:
Florian G. Pflug wrote:
bison -y -d gram.y
conflicts: 2 shift/reduce
I'ts been quite a time since I last used bison, but as far as I
remember, you can tell it to write a rather details log about
it's analysis of the grammar. That log should include more
detailed
Tom Lane írta:
...
If anyone seriously wants to propose removing postfix ops from b_expr,
we'd better take it up on someplace more widely read than -patches.
regards, tom lane
OK, I take the bullet and send it to -hackers.
For everyone who don't read -patches, let
Martijn van Oosterhout írta:
On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token of
lookahead than we have to tell
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Martijn van Oosterhout írta:
On Thu, Apr 19, 2007 at 11:19:40AM +0200, Zoltan Boszormenyi wrote:
The problem comes from cases like
colname coltype DEFAULT 5! GENERATED ...
Since b_expr allows postfix operators, it takes one more token
Tom Lane írta:
After some more study of the SQL spec, the distinction between GENERATED
ALWAYS AS IDENTITY and GENERATED BY DEFAULT AS IDENTITY is not what
I thought it was.
* As far as I can find from the spec, there is *no* difference between
the two cases for INSERT commands. The rule is
Zoltan Boszormenyi írta:
The quoted SIGMOD paper mentioned that specifying a value
for a generated column should raise an error in INSERT but
this behaviour is not mentioned by the standard.
I found it now, I haven't read hard enough before.
SQL:2003, section 14.8, syntax rules:
10
Hi,
we at Cybertec have developed cast functions in C between
inet/cidr - bytea for a client and we would like to submit it.
This is how it works:
- IPv4 inet/cidr value will return 4 bytes if the netmask covers all 32
bits.
It returns 5 bytes if the netmask is shorter than 32 bits.
-
Bruce Momjian írta:
Zoltan Boszormenyi wrote:
Hi,
we at Cybertec have developed cast functions in C between
inet/cidr - bytea for a client and we would like to submit it.
This is how it works:
- IPv4 inet/cidr value will return 4 bytes if the netmask covers all 32
bits.
It returns 5
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
we at Cybertec have developed cast functions in C between
inet/cidr - bytea for a client and we would like to submit it.
Why is this a good idea? Exposing the internal representation of a
datatype is usually bad.
I didn't
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Bruce Momjian írta:
What is the use case for such a cast?
The application doesn't want to parse the textual IP address
when all the parsing and checking intelligence is already there
in the inet/cidr type checks
Tom Lane írta:
It's hard to see how anyone could be doing 6K xacts/sec unless most are
read-only.
regards, tom lane
In a recent stress test with our PostgreSQL-based cluster between two
machines
3 million transaction were performed with pgbench -c 150 -t 2 -s
Heikki Linnakangas írta:
Zoltan Boszormenyi wrote:
Tom Lane írta:
It's hard to see how anyone could be doing 6K xacts/sec unless most are
read-only.
In a recent stress test with our PostgreSQL-based cluster between two
machines
3 million transaction were performed with pgbench
Decibel! írta:
On Mar 25, 2008, at 11:40 AM, Zoltan Boszormenyi wrote:
All of them? PostgreSQL allow multiple SERIALs to be present,
the standard allows only one IDENTITY column in a table.
And what about this case below?
CREATE TABLE t1 (id1 serial, ...);
ALTER SEQUENCE seq_t1_id1 RESTART
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's the START WITH option
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust the minimum value.
There's
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
Decibel! írta:
On Apr 3, 2008, at 12:52 AM, Zoltan Boszormenyi wrote:
Where is the info in the sequence to provide restarting with
the _original_ start value?
There isn't any. If you want the sequence to start at some magic
value, adjust
Hi,
Zoltan Boszormenyi írta:
Updated patch implements TRUNCATE ... RESTART IDENTITY
which restarts all owned sequences for the truncated table(s).
Regression tests updated, documentation added. pg_dump was
also extended to output original[1] START value for creating SEQUENCEs.
[1] For 8.3
Hi,
we have a customer who shot themselves in the foot by using
table names with german accented characters in them.
The client application on the popular OS is using a single-byte
encoding (LATIN9), their dump of the original database is using
the same but no SET client_encoding = ... line
Martijn van Oosterhout írta:
On Wed, Apr 23, 2008 at 10:02:37AM +0200, Zoltan Boszormenyi wrote:
But the question popped up whether PostgreSQL can be extended
to allow localized literals and apply encoding conversion the same
way as on string data. NAMEDATA can be replaced with regular TEXT
Martijn van Oosterhout írta:
On Wed, May 07, 2008 at 03:04:49PM -0700, David Fetter wrote:
1. Create a generic (possibly overloaded) trigger function, bundled
with PostgreSQL, which sets a field to some value. For example, a
timestamptz version might set the field to now().
Doesn't
Zoltan Boszormenyi írta:
Martijn van Oosterhout írta:
On Wed, May 07, 2008 at 03:04:49PM -0700, David Fetter wrote:
1. Create a generic (possibly overloaded) trigger function, bundled
with PostgreSQL, which sets a field to some value. For example, a
timestamptz version might set the field
Gregory Stark írta:
This is indeed really cool. I'm sorry I haven't gotten to doing what I
promised in this area but I'm glad it's happening anyways.
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Can we get the rows in tree order, please?
...
After all, I didn't specify any ORDER
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
The standard has a clause to specify depth-first order. However doing a
depth-first traversal would necessitate quite a different looking plan and
it's far less obvious (to me anyways) how to do
Yoshiyuki Asaba írta:
Hi,
From: Zoltan Boszormenyi [EMAIL PROTECTED]
Subject: Re: [PATCHES] WITH RECURSIVE patch V0.1
Date: Mon, 19 May 2008 08:19:17 +0200
Also, it seems there are no infinite recursion detection:
# with recursive x(level, parent, child) as (
select 1::integer, * from
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 08:19:17AM +0200, Zoltan Boszormenyi wrote:
The standard has a clause to specify depth-first order. However doing a
depth-first traversal would necessitate quite a different looking plan and
it's far less obvious (to me anyways) how to do
Martijn van Oosterhout írta:
On Mon, May 19, 2008 at 11:56:17AM +0200, Zoltan Boszormenyi wrote:
From an implementation point of view, the only difference between
breadth-first and depth-first is that your tuplestore needs to be LIFO
instead of FIFO.
Are you sure? I think
Gregory Stark írta:
Martijn van Oosterhout [EMAIL PROTECTED] writes:
From an implementation point of view, the only difference between
breadth-first and depth-first is that your tuplestore needs to be LIFO
instead of FIFO.
I think it's not so simple. How do you reconcile that
Hm. Someone had his second finger chainsawed? Where is 8.3.2?
The ftp browser also shows 8.3.1 and 8.3.3, and 8.3.1 is the latest on
the main page.
Rawhide írta:
postgresql-8.3.3-1.fc10
---
* Wed Jun 11 18:00:00 2008 Tom Lane [EMAIL PROTECTED] 8.3.3-1
- Update to
Thanks for the info.
Magnus Hagander írta:
8.3.2 was pulled back because of an urgent bugfix, and re-released as
8.3.3 since it had already hit the mirrors.
8.3.3 has not been officially releasde yet, but it will be out soon.
//Magnus
Zoltan Boszormenyi wrote:
Hm. Someone had his
Jeffrey Baker írta:
The way I read it, the current btree index stores the index value and
the TID of every tuple having that value. When you have a table with
three columns, you index one of them and you get an index which is
practically as large as the table itself.
Supposing the table is
Jeffrey Baker írta:
On Tue, Jun 24, 2008 at 1:59 PM, Zoltan Boszormenyi [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Jeffrey Baker írta:
The way I read it, the current btree index stores the index
value and
the TID of every tuple having that value. When you have
Heikki Linnakangas írta:
Hans-Juergen Schoenig wrote:
at the moment i am working on an application which is supposed to run
extremely large transactions (a lot of server side stored procedure
stuff which can hardly be split into small transactions for visibility
reasons).
so, from time to
Hi,
we came across a problem when you want to dump only one schema.
The ASCII output when loaded with psql into an empty database
doesn't produce an identical schema to the original.
The problem comes from this statement ordering:
SET ... -- some initial DB parameters
...
SET search_path =
Hi,
please don't top post to someone who didn't used this convention
in answering you. It's impolite. I edited the mail a bit to return sanity.
On Nov 29, 2007 9:00 PM, Douglas McNaught [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
On 11/29/07, [EMAIL PROTECTED] mailto:[EMAIL
Hi,
as the wishlist for PostgreSQL 8.4 still has my
IDENTITY/GENERATED patches, I thought I refresh it.
Before actually doing it though, I wanted to ask for opinions
on implementation and ideas.
Here are the general ideas that were done by my patch:
1. IDENTITY columns.
The IDENTITY columns
Doug Knight írta:
All,
I am trying to build 8.2.5, forcing to a 32 bit build on a 64 bit
system. I have set CFLAGS=-m32, and I run the configure and make/make
install as follows:
setarch i386 ./configure
setarch i386 make
setarch i386 make install
However, I get the following error (using
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
as the wishlist for PostgreSQL 8.4 still has my
IDENTITY/GENERATED patches, I thought I refresh it.
Before actually doing it though, I wanted to ask for opinions
on implementation and ideas.
IIRC the end conclusion
Hi,
what's your opinion on this?
I saw response only from Alvaro on the -patches list.
Thanks in advance,
Zoltán Böszörményi
Eredeti üzenet
Tárgy: Re: [PATCHES] 64-bit CommandIds
Dátum: Tue, 04 Mar 2008 21:52:25 +0100
Feladó: Zoltan Boszormenyi [EMAIL PROTECTED
Simon Riggs írta:
On Tue, 2008-03-25 at 09:08 -0700, Steve Crawford wrote:
Simon Riggs wrote:
RESTART IDENTITY will reset the SERIAL sequences back to the original
start value.
Assuming this feature were to be added
In cases where the same sequence has been used across
Zoltan Boszormenyi írta:
Simon Riggs írta:
On Tue, 2008-03-25 at 09:08 -0700, Steve Crawford wrote:
Simon Riggs wrote:
RESTART IDENTITY will reset the SERIAL sequences back to the original
start value.
Assuming this feature were to be added
In cases where the same
Matt Miller írta:
The [pgcluster-1.7.0rc1-patch] patch applies to the 8.2.0 tarball ...
However, the patch will not apply to cvs branch REL8_2_0.
I've been told that the pgcluster patch patches some generated files
(parse.h and other apparently).
Yes, I could not at first apply to
Hi,
I started working again on my
IDENTITY/GENERATED patch.
My question is $SUBJECT.
This code is in rewriteTargetlist():
new_attr = build_column_default()
new_tle = makeTargetEntry((Expr *) new_expr, ...)
Now, in ExecInsert() I have to compute
the default for IDENTITY/GENERATED
between
Hi,
I started working on my previous patch, encouraged
by the fact that it became a wishlist item for 8.3. :-)
The changes in this version are:
- Refreshed to almost current (5 days old)
CVS version of 8.3 devel
- The original SERIAL pseudo type is left alone,
you _have to_ spell out
Hi,
this is with current CVS code:
# \dt
ERROR: did not find '}' at end of input node
Server log:
ERROR: did not find '}' at end of input node
STATEMENT: SELECT n.nspname as Schema,
c.relname as Name,
CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN
'i'
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Hi,
this is with current CVS code:
# \dt
ERROR: did not find '}' at end of input node
Server log:
ERROR: did not find '}' at end of input node
It's working for me. Have you tried with a fresh checkout or after
running make clean before you
Hi,
I would like to be able to harden the conditions
of generating IDENTITY columns so the
events below run in this order:
- assign values for regular columns (with or without DEFAULT)
- NOT NULL checks on regular columns
- CHECK constraints whose expression contains only regular columns
-
Hi,
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
Would it be acceptable?
No, because you can't create index entries when you haven't yet got the
TID for the heap tuple. What do you propose doing, insert a dummy index
entry and then go back to fill it in later? Aside
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
cannot skip a value
Zoltan Boszormenyi írta:
Florian G. Pflug írta:
Zoltan Boszormenyi wrote:
The GENERATED column is an easy of use feature
with possibly having less work, whereas the IDENTITY
column is mandatory for some applications (e.g. accounting
and billing is stricter in some countries) where you simply
Florian G. Pflug írta:
Yes, of course you can prevent gaps by just filling them
with garbage/invalid records of whatever. But I don't see
why this is usefull - either you want, say, your invoice
number to be continuous because it's required by law - or
you don't. But if the law required your
Zoltan Boszormenyi írta:
The cost I am thinking now is an extra heap_update()
after heap_insert() without generating the identity value
and inserting index tuples to indexes that doesn't
contain the identity column.
And as far as I tested the current state, there is no cost
if you don't use
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
However, I get warning messages like:
WARNING: detected write past chunk end in ExecutorState 0xaaff68
How can I prevent them?
Find the memory-clobbering bug in your patch.
regards, tom lane
Hi,
I made some tests to prove that GENERATED can help
boost performance. I created a table like this:
create table t1 (
id serial,
i1 integer,
i2 integer,
g1 integer generated always as (
case when i1 is null then i2
when i2 is null then i1
else i1
Hi,
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
$ uname -a
SunOS dev-machine 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V440
It seems that somehow the system provided
GCC 3.4.3 miscompiles timestamptz_send()
and it
Zdenek Kotala írta:
Zoltan Boszormenyi wrote:
Hi,
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
$ uname -a
SunOS dev-machine 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V440
It seems that somehow the system provided
Tom Lane írta:
Zoltan Boszormenyi [EMAIL PROTECTED] writes:
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
...
It seems that somehow the system provided
GCC 3.4.3 miscompiles timestamptz_send()
and it segfaults.
I
Zoltan Boszormenyi írta:
Zdenek Kotala írta:
Zoltan Boszormenyi wrote:
Hi,
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
$ uname -a
SunOS dev-machine 5.10 Generic_118833-36 sun4u sparc SUNW,Sun-Fire-V440
It seems
Zoltan Boszormenyi írta:
Zoltan Boszormenyi írta:
Zdenek Kotala írta:
Zoltan Boszormenyi wrote:
Hi,
we have found that psql in PostgreSQL 8.2.3
has problems connecting to the server
running on Solaris 10/Sun SPARC.
$ uname -a
SunOS dev-machine 5.10 Generic_118833-36 sun4u sparc
SUNW,Sun
95 matches
Mail list logo
