Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Tom Lane írta:
>> Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
>>> Yes. Plain SERIALs can be updated with given values
>>> whereas IDENTITY columns cannot.
>>
>> Really? How is pg_dump going to deal with that?
> It emits ALTER TABLE ... SET GENE
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
Tom Lane írta:
The latter would treat GENERATED BY DEFAULT AS IDENTITY
the same as SERIAL.
Is there any good reason to distinguish the two?
Yes. Plain SERIALs can be updated with given values
where
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Uh, shouldn't CREATE TABLE LIKE INCLUDING CONSTRAINTS already be including
> any indexes in the parent table?
You could argue it should for unique indexes since our unique indexes are how
we implement unique constraints. But I see no particular reason
Uh, shouldn't CREATE TABLE LIKE INCLUDING CONSTRAINTS already be including
any indexes in the parent table?
---
Trevor Hardcastle wrote:
> Greetings all,
>
> I wrote this patch about a week ago to introduce myself to coding
Joshua D. Drake wrote:
> Alvaro Herrera wrote:
> >ITAGAKI Takahiro wrote:
> >>Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> >>
> >>>Here is the autovacuum patch I am currently working with. This is
> >>>basically the same as the previous patch; I have tweaked the database
> >>>list management so tha
> Tatsuo, would you please comment on this patch too?
No problem. I will come up with a comment by the end of this week.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> ---
>
> Greg Smith wrote:
> > This patch changes the way pgbench
> Tatsuo, would you please comment on this patch?
Sure. I will come up with a comment by the end of this week.
--
Tatsuo Ishii
SRA OSS, Inc. Japan
> ---
>
> ITAGAKI Takahiro wrote:
> > The attached is a patch to optimize con
Tatsuo, would you please comment on this patch too?
---
Greg Smith wrote:
> This patch changes the way pgbench outputs its latency log files so that
> every transaction gets a timestamp and notes which transaction type was
Tatsuo, would you please comment on this patch?
---
ITAGAKI Takahiro wrote:
> The attached is a patch to optimize contrib/pgbench using new 8.3 features.
>
> - Use DROP IF EXISTS to suppress errors for initial loadings.
> -
Alvaro Herrera wrote:
ITAGAKI Takahiro wrote:
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
Here is the autovacuum patch I am currently working with. This is
basically the same as the previous patch; I have tweaked the database
list management so that after a change in databases (say a new databa
ITAGAKI Takahiro wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> wrote:
>
> > Here is the autovacuum patch I am currently working with. This is
> > basically the same as the previous patch; I have tweaked the database
> > list management so that after a change in databases (say a new database
> > is
I have applied the following patch which adds documentation and an
improved error message for an installation that does not use
--with-libxml.
---
Nikolay Samokhvalov wrote:
> On 4/5/07, Bruce Momjian <[EMAIL PROTECTED]> wro
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> Here is the autovacuum patch I am currently working with. This is
> basically the same as the previous patch; I have tweaked the database
> list management so that after a change in databases (say a new database
> is created or a database is dropped), t
> On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> >
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> >
> Thanks Bruce. I would like to submit atleast one more revision
> which would include couple of TODOs mentioned in my last mail.
> I would also like to d
On Wednesday April 4 2007 5:37 pm, Bruce Momjian wrote:
> > Perhaps this could be added to the TODO list? I won't get
> > to it anytime soon.
>
> Yes. What should the TODO text be?
See if the attached patch is acceptable. If not, perhaps the
TODO text should be:
Enable end user to identify de
Alvaro Herrera wrote:
Hi,
uhmmm patch?
Here is the autovacuum patch I am currently working with. This is
basically the same as the previous patch; I have tweaked the database
list management so that after a change in databases (say a new database
is created or a database is dropped), the
Alvaro Herrera wrote:
> Hi,
>
> Here is the autovacuum patch I am currently working with.
Obviously I forgot to attach the patch, sorry.
--
Alvaro Herrera Developer, http://www.PostgreSQL.org/
"Para tener más hay que desear menos"
Index: src/backend/postmaster/autovacuu
Hi,
Here is the autovacuum patch I am currently working with. This is
basically the same as the previous patch; I have tweaked the database
list management so that after a change in databases (say a new database
is created or a database is dropped), the list is recomputed to account
for the chang
Pavan Deolasee wrote:
> On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> >
> > Your patch has been added to the PostgreSQL unapplied patches list at:
> >
> >
> Thanks Bruce. I would like to submit atleast one more revision
> which would include couple of TODOs mentioned in my last mail.
>
Peter Eisentraut wrote:
And if it is, then you have several options:
. don't configure with libxml, or
. don't build contrib modules from the contrib Makefile (use the
individual module Makefiles instead), or
. change the xml2 Makefile
Any of these could be worth considering, but it needs
Andrew Dunstan wrote:
> Well, how often is libxslt missing when libxml is present, in
> practice?
A local sample shows a probability of 100%.
> And if it is, then you have several options:
> . don't configure with libxml, or
> . don't build contrib modules from the contrib Makefile (use the
> in
Jaime Casanova wrote:
> On 4/2/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
> >
> > This has been saved for the 8.4 release:
> >
> >http://momjian.postgresql.org/cgi-bin/pgpatches_hold
> >
>
> mmm... sorry, i have been busy... how many time we have? i can send
> something for friday...
Ye
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Tom Lane írta:
>>> The latter would treat GENERATED BY DEFAULT AS IDENTITY
>>> the same as SERIAL.
>> Is there any good reason to distinguish the two?
> Yes. Plain SERIALs can be updated with given values
> whereas IDENTITY columns cannot.
Really?
Peter Eisentraut wrote:
Andrew Dunstan wrote:
Since contrib/xml2 seems to be staying with us at least for now, this
small patch enables it to be built and installed from the contrib
Makefile when --with-libxml is given to configure.
contrib/xml2 also requires libxslt.
Well, how oft
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.
What about IDENTITY?
Should it also be part of pg_attrdef?
Andrew Dunstan wrote:
> Since contrib/xml2 seems to be staying with us at least for now, this
> small patch enables it to be built and installed from the contrib
> Makefile when --with-libxml is given to configure.
contrib/xml2 also requires libxslt.
--
Peter Eisentraut
http://developer.postgres
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.
> What about IDENTITY?
> Should it also be part of pg_attrdef? There are two ways
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
I have two questions about the dependency system.
1. Is there a built-in defense to avoid circular dependencies?
It doesn't have a problem with them, if that's what you mean.
2. If I register dependencies bet
Since contrib/xml2 seems to be staying with us at least for now, this
small patch enables it to be built and installed from the contrib
Makefile when --with-libxml is given to configure.
If there's no objection I'll apply in a day or two.
cheers
andrew
Index: configure
=
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> I have two questions about the dependency system.
> 1. Is there a built-in defense to avoid circular dependencies?
It doesn't have a problem with them, if that's what you mean.
> 2. If I register dependencies between column, is there a way
> t
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
Before you get too excited about making generated columns disappear
automatically in all these cases, consider that dropping a column
is not something to be done lightly --- it might contain irreplaceable
data.
The sta
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
>> Before you get too excited about making generated columns disappear
>> automatically in all these cases, consider that dropping a column
>> is not something to be done lightly --- it might contain irreplaceable
>> data.
> The standard says that the
Tom Lane írta:
I wrote:
I see another problem with this patch: the code added to
ATExecDropColumn is a crude hack. It doesn't work anyway since this is
not the only possible way for columns to be dropped (another one that
comes to mind immediately is DROP TYPE ... CASCADE). The only correct
On 4/3/07, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Your patch has been added to the PostgreSQL unapplied patches list at:
Thanks Bruce. I would like to submit atleast one more revision
which would include couple of TODOs mentioned in my last mail.
I would also like to do some cleanup and co
I wrote:
> I see another problem with this patch: the code added to
> ATExecDropColumn is a crude hack. It doesn't work anyway since this is
> not the only possible way for columns to be dropped (another one that
> comes to mind immediately is DROP TYPE ... CASCADE). The only correct
> way to han
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> Here's the new version with the modifications you requested.
I see another problem with this patch: the code added to
ATExecDropColumn is a crude hack. It doesn't work anyway since this is
not the only possible way for columns to be dropped (anothe
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
The idea wouldn't have considered to cross my mind
if Tom didn't mention the action-at-a-distance behaviour.
AFAIR, that remark had to do with NEXT VALUE FOR, which SQL2003 defines
in a very weird way (it's not equivalent to
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
> The idea wouldn't have considered to cross my mind
> if Tom didn't mention the action-at-a-distance behaviour.
AFAIR, that remark had to do with NEXT VALUE FOR, which SQL2003 defines
in a very weird way (it's not equivalent to nextval() as one would
Andrew Dunstan írta:
Zoltan Boszormenyi wrote:
Tom Lane írta:
- unique index checks are done in two steps
to avoid inflating the sequence if a unique index check
is failed that doesn't reference the IDENTITY column
This is just not acceptable --- there is nothing in the standard tha
On 4/4/07, Nikolay Samokhvalov <[EMAIL PROTECTED]> wrote:
So, choosing between two inefficient approaches:
1. mine, which in some cases use dummy element wrapping, that we could
escape;
2. proposed by you, which leads to +1 parsing.
... I'd definitely choose the first one.
I'd make it a bi
Am Mittwoch, 4. April 2007 15:20 schrieb Nikolay Samokhvalov:
> > To determine if an XML datum is a document, call xml_is_document(). The
> > implementation of that function is probably not the best possible one,
> > but what the xpath() code does it totally wrong nevertheless.
>
> You are proposi
Am Mittwoch, 4. April 2007 14:43 schrieb Nikolay Samokhvalov:
> > Why do we even need to support xpath on fragments?
>
> Why not? I find it useful and convenient.
Well, rather than inventing bogus root wrapper elements, why not let users
call xmlelement() to produce the wrapper element themselves
Zoltan Boszormenyi wrote:
Tom Lane írta:
- unique index checks are done in two steps
to avoid inflating the sequence if a unique index check
is failed that doesn't reference the IDENTITY column
This is just not acceptable --- there is nothing in the standard that
requires such behavi
Am Mittwoch, 4. April 2007 14:42 schrieb Nikolay Samokhvalov:
> > Why is the function not strict?
>
> Because in case of 3rd argument (NS mappings) being NULL, we shouldn't
> return NULL immediately:
If the namespace mapping is NULL then it is unknown, and therefore the result
of the XPath expres
Am Mittwoch, 4. April 2007 14:42 schrieb Nikolay Samokhvalov:
> Maybe it's worth to start keeping additional information in xml datum (i.e.
> bit IS_DOCUMENT and, what is more important for xpath() function, a bit
> indicating that XML value has only one root and can be considered as a tree
> => th
Tom Lane írta:
Zoltan Boszormenyi <[EMAIL PROTECTED]> writes:
[ IDENTITY/GENERATED patch ]
I got around to reviewing this today.
Thanks for the review.
Sorry for the bit late reply, I was ill and
then occupied with some other work.
- unique index checks are done in two steps
t
FAST PostgreSQL wrote:
On Wed, 4 Apr 2007 02:26, Andrew Dunstan wrote:
I am currently doing the following modifications to the patch as per the
review comments.
1. Changing all references to 'sqllog' or 'sql' to 'csvlog' and 'csv'
respectively.
2. Escaping the username and databasename
3. C
47 matches
Mail list logo
