> The other day there was a discussion around the fact that X'' will
> get converted into an integer constant...
> ... while SQL99 says that this syntax *should* be used to specify a
> "binary string". It looks like the hex-to-integer magic actually occurs
> in the lexer, and then the integer
On Fri, 12 Apr 2002 12:58:01 +0900
"Hiroshi Inoue" <[EMAIL PROTECTED]> wrote:
> Tom Lane wrote:
> >
> > I'm not sure I believe Hannu's numbers, but in any case they're fairly
> > irrelevant to the argument about whether a special protocol is useful.
> > He wasn't testing textually-long queries, b
Bruce Momjian wrote:
>
> Hiroshi Inoue wrote:
> > Christopher Kings-Lynne wrote:
> > >
> I think that is why Tom was suggesting making all the column values NULL
> and removing the pg_attribute row for the column. With a NULL value, it
> doesn't take up any room in the tuple, and with the pg_attr
Tom Lane wrote:
>
> I'm not sure I believe Hannu's numbers, but in any case they're fairly
> irrelevant to the argument about whether a special protocol is useful.
> He wasn't testing textually-long queries, but rather the planning
> overhead, which is more or less independent of the length of any
Ashley Cambrell <[EMAIL PROTECTED]> writes:
> I remember an email Hannu sent (I originally thought Tome sent it but I
> found the email*) that said postgresql spends a lot of time parsing sql
> (compared to oracle), so if the BE/FE and libpq were extended to support
> pg_prepare / pg_bind, then it
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I think that is why Tom was suggesting making all the column values NULL
> and removing the pg_attribute row for the column.
That was not my suggestion.
> With a NULL value, it
> doesn't take up any room in the tuple, and with the pg_attribute column
>
> Fine. I'll work on that basis. I'll prepare a full-blown patch which can
> be applied Monday -unless anyone else is sitting on uncommitted changes
> to the directory that they want me to wait for?
Nothing important. Shall I suggest that you do the rearrangement first, and
then once everything'
Hiroshi Inoue wrote:
> Christopher Kings-Lynne wrote:
> >
> > Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is
> > kinda useless - you may as well just use a view!!!
> >
> > So how would this occur?:
> >
> > 1. Lock target table for writing (allow reads)
> > 2. Begin a
On 11 Apr 2002, Hannu Krosing wrote:
> IIRC someone started work on modularising the network-related parts with
> a goal of supporting DRDA (DB2 protocol) and others in future.
That was me, although I've been bogged down lately, and haven't been able
to get back to it. DRDA, btw, is not just a
On Thu, 11 Apr 2002 11:38:33 -0700
"Barry Lind" <[EMAIL PROTECTED]> wrote:
> Neil Conway wrote:
> > On Thu, 11 Apr 2002 16:25:24 +1000
> > "Ashley Cambrell" <[EMAIL PROTECTED]> wrote:
> >
> >>What are the chances that the BE/FE will be altered to take advantage of
> >>prepare / execute? Or is it
Just to let you know that you can use the transfer
tool of the hsqldb JAVA database to transfer database from Informix to Postgres.
I have used it to transfer my application from IDS 7.3 to Postgres 7.2.1.
Because it relies on JDBC, it can be used/expended to
support other databases.
It s
Christopher Kings-Lynne wrote:
>
> Hmmm. Personally, I think that a DROP COLUMN that cannot reclaim space is
> kinda useless - you may as well just use a view!!!
>
> So how would this occur?:
>
> 1. Lock target table for writing (allow reads)
> 2. Begin a table scan on target table, writing
>
Neil Conway wrote:
>On Thu, 11 Apr 2002 16:25:24 +1000
>"Ashley Cambrell" <[EMAIL PROTECTED]> wrote:
>
>>What are the chances that the BE/FE will be altered to take advantage of
>>prepare / execute? Or is it something that will "never happen"?
>>
>
>Is there a need for this? The current patch I'
On Thu, 2002-04-11 at 15:33, Tom Lane wrote:
>
> > That shouldn't be too much of a problem in the next couple of weeks - if
> > we can decide on a specific day I'll book it into my diary (Any day but
> > Wednesday next week would be fine for me).
>
> I will try to have no uncommitted changes over
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> I was slightly bemused to notice that your implementation of it for
>> regular functions tests the privilege at plan startup but doesn't
>> actually throw the error until the function is called. What's the
>> point of that? Seems
Tom Lane writes:
> I was slightly bemused to notice that your implementation of it for
> regular functions tests the privilege at plan startup but doesn't
> actually throw the error until the function is called. What's the
> point of that? Seems like we might as well throw the error in
> init_fc
Jan Wieck wrote:
> Bruce Momjian wrote:
> > Jan Wieck wrote:
> > > > The hard limit is certainly no more than 64K, since we store these
> > > > numbers in half of an atttypmod. In practice I suspect the limit may
> > > > be less; Jan would be more likely to remember...
> > >
> > > It is arbit
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Tom Lane writes:
>> Why shouldn't aggregate functions have entries in pg_proc? Then one
>> search would cover both possibilities, and we could eliminate some
>> duplicate code in the parser.
> Furthermore, we could make the new function privileges a
Tom Lane wrote:
> It would be interesting to see some stats for the large-BLOB scenarios
> being debated here. You could get more support for the position that
> something should be done if you had numbers to back it up.
Below are some stats you did a few months ago when I was asking a
rel
Barry Lind <[EMAIL PROTECTED]> writes:
> ...
> Since we
> don't currently provide any information to the user on the relative cost
> of the parse, plan and execute phases, the end user is going to be
> guessing IMHO.
You can in fact get that information fairly easily; set
show_parser_stats, s
Since it seems we still want to debate this a little, I've modified the
initial set of implicit-coercion-allowed flags to allow silent coercions
from the standard datatypes to text. This un-breaks most of the
regression tests that were failing before. I still want to debate the
wisdom of allowin
> -Original Message-
> From: PJourdan [mailto:[EMAIL PROTECTED]]
> Sent: 11 April 2002 17:24
> To: [EMAIL PROTECTED]
> Subject: [pgadmin-support] migration problem
>
>
> I know this is not strictly a pgadmin issue, but I don't know
> where else to
> turn.
> At worst, perhaps someone
Neil Conway wrote:
> On Thu, 11 Apr 2002 16:25:24 +1000
> "Ashley Cambrell" <[EMAIL PROTECTED]> wrote:
>
>>What are the chances that the BE/FE will be altered to take advantage of
>>prepare / execute? Or is it something that will "never happen"?
>
>
> Is there a need for this? The current pa
Joe Conway writes:
> The other day there was a discussion around the fact that X'' will
> get converted into an integer constant, e.g.
> , while SQL99 says that this syntax *should* be used to specify a
> "binary string".
Actually, SQL99 is ambiguous regarding whether it represents a blob o
Am Donnerstag, 11. April 2002 17:44 schrieb Tom Lane:
> "Mario Weilguni" <[EMAIL PROTECTED]> writes:
> > And I did not find out how I can detect the large object
> > chunksize, either from getting it from the headers (include
> > "storage/large_object.h" did not work)
>
You did not answer if it's
On Thu, 2002-04-11 at 18:14, Tom Lane wrote:
> Neil Conway <[EMAIL PROTECTED]> writes:
> > On the other hand, there are already a few reasons to make some
> > changes to the FE/BE protocol (NOTIFY messages, transaction state,
> > and now possibly PREPARE/EXECUTE -- anything else?).
>
> Passing EX
Thomas Lockhart <[EMAIL PROTECTED]> writes:
> We have never been in complete agreement on the optimal behavior for
> type coersion, but it seems that most users are blissfully ignorant of
> the potential downsides of the current behavior. Another way to phrase
> that would be to say that it actual
Tom Lane wrote:
> Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> > The real problem here is the fact that there are now missing attnos in
> > pg_attribute. Either that's handled or we renumber the attnos - which is
> > also quite hard?
>
> Updating pg_attribute per se is not so hard --- j
On Thu, 11 Apr 2002, Tom Lane wrote:
> Gavin Sherry <[EMAIL PROTECTED]> writes:
> > PrepareStmt: PREPARE name AS prepare_query types_prepare_clause
> > prepare_store
>
> > There is a reasonably clear problem here. prepare_query encompasses much
> > of the grammar of the parser so it will defina
Neil Conway wrote:
> On Wed, 10 Apr 2002 22:36:49 -0700 "Barry Lind" <[EMAIL PROTECTED]>
> wrote:
>
>> Neil,
>>
>> Will this allow you to pass bytea data as binary data in the
>> parameters section (ability to bind values to parameters) or will
>> this still require that the data be passed
Christopher Kings-Lynne wrote:
> > Actually, what we need to do to reclaim space is to enable table
> > recreation without the column, now that we have relfilenode for file
> > renaming. It isn't hard to do, but no one has focused on it. I want to
> > focus on it, but have not had the time, obvi
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
> The real problem here is the fact that there are now missing attnos in
> pg_attribute. Either that's handled or we renumber the attnos - which is
> also quite hard?
Updating pg_attribute per se is not so hard --- just store new copies of
all
On Thu, 11 Apr 2002 15:02:49 +1000 (EST)
"Gavin Sherry" <[EMAIL PROTECTED]> wrote:
> On Wed, 10 Apr 2002, Neil Conway wrote:
>
> > Hi all,
> >
> > I'm working on a fairly large patch (cleaning up Karel Zak's
> > PREPARE/EXECUTE work), and I'm having some problems with bison (I'm
> > a yacc newbi
Neil Conway <[EMAIL PROTECTED]> writes:
> On the other hand, there are already a few reasons to make some
> changes to the FE/BE protocol (NOTIFY messages, transaction state,
> and now possibly PREPARE/EXECUTE -- anything else?).
Passing EXECUTE parameters without having them go through the parse
...
> Since I didn't see an immediate batch of squawks, I think I will go
> ahead and commit what I have; we can always revisit the implicit-allowed
> flag settings later.
Squawk. But I haven't had time to look at the full ramifications of your
proposed change, so it is inappropriate to comment,
On Thu, 11 Apr 2002, Mario Weilguni wrote:
> As promised here's an example of deadlock using foreign keys.
>
> create table lang (
> id integer not null primary key,
> name text
> );
> insert into lang values (1, 'English');
> insert into lang values (2, 'German');
>
> create table country (
On Wed, 10 Apr 2002 22:36:49 -0700
"Barry Lind" <[EMAIL PROTECTED]> wrote:
> Neil,
>
> Will this allow you to pass bytea data as binary data in the parameters
> section (ability to bind values to parameters) or will this still
> require that the data be passed as a text string that the parser n
On Thu, 11 Apr 2002, Bruce Momjian wrote:
> Is anyone feeling we have the 7.3 release nearing? I certainly am not.
> I can imagine us going for several more months like this, perhaps
> through August.
seeing as how we just released v7.2, I don't see a v7.3 even going beta
until end of Summer ..
> Actually, what we need to do to reclaim space is to enable table
> recreation without the column, now that we have relfilenode for file
> renaming. It isn't hard to do, but no one has focused on it. I want to
> focus on it, but have not had the time, obviously, and would be very
> excited to a
Barry Lind <[EMAIL PROTECTED]> writes:
> OK. My mistake. In looking at the regression failures in your post, I
> thought I saw errors being reported of this type. My bad.
Well, although that particular case isn't a problem, I am sure that this
change will break some existing applications ---
On Thu, 11 Apr 2002 16:25:24 +1000
"Ashley Cambrell" <[EMAIL PROTECTED]> wrote:
> What are the chances that the BE/FE will be altered to take advantage of
> prepare / execute? Or is it something that will "never happen"?
Is there a need for this? The current patch I'm working on just
does everyt
Nicolas Bazin writes:
> For the next release and package it would be good to differentiate the
> release candidate to the proper release.
They do have different names.
--
Peter Eisentraut [EMAIL PROTECTED]
---(end of broadcast)---
TIP 3: if p
Gavin Sherry <[EMAIL PROTECTED]> writes:
> PrepareStmt: PREPARE name AS prepare_query types_prepare_clause
> prepare_store
> There is a reasonably clear problem here. prepare_query encompasses much
> of the grammar of the parser so it will definately cause shift/reduce and
> reduce/reduce confli
"Mario Weilguni" <[EMAIL PROTECTED]> writes:
> And I did not find out how I can detect the large object
> chunksize, either from getting it from the headers (include
> "storage/large_object.h" did not work)
Why not?
Still, it might make sense to move the LOBLKSIZE definition into
pg_config.h, si
Christopher Kings-Lynne <[EMAIL PROTECTED]> writes:
>> What's insufficiently generic about them for you?
> Well, at a _quick_ glance they're designed only for one column output...
Well, exactly. These are intended to be a convenient interface for that
case. They're already sitting on top of ge
> > I should really move these off somewhere else and make them a bit more
> > global and generic.
>
> What's insufficiently generic about them for you?
Well, at a _quick_ glance they're designed only for one column output...
Chris
---(end of broadcast)
"Christopher Kings-Lynne" <[EMAIL PROTECTED]> writes:
> static TextOutputState *begin_text_output(CommandDest dest, char *title);
> static void do_text_output(TextOutputState *tstate, char *aline);
> static void do_text_output_multiline(TextOutputState *tstate, char *text);
> static void end_text_
As promised here's an example of deadlock using foreign keys.
create table lang (
id integer not null primary key,
name text
);
insert into lang values (1, 'English');
insert into lang values (2, 'German');
create table country (
id integer not null primary key,
name text
);
insert into
John Gray <[EMAIL PROTECTED]> writes:
> I have compiled a new version against current CVS, now also including
> references to dependencies (See below). I accept that we'll need to work
> round the schema project -in the week since the last message I notice
> that namespace support has arrived for
On Wed, 2002-04-03 at 16:52, Tom Lane wrote:
> John Gray <[EMAIL PROTECTED]> writes:
> > Here's my current working draft (doesn't include material from the
> > last couple of weeks):
>
> Please note that there's been pretty substantial revisions in command.c
> and creatinh.c over the past couple
> We'll need a good beta period this time, because of:
I know it's a sore subject, but how about "ALTER TABLE DROP COLUMN" this
time around? I've been hearing about it for years now. :)
- brandon
c: 646-456-5455
Hi,
I'm working on making the SHOW command dump its output as if it were a
select result.
Tom's declared the following as static ("private") methods?
static TextOutputState *begin_text_output(CommandDest dest, char *title);
static void do_text_output(TextOutputState *tstate, char *aline);
stati
I've detected that the restoring of large objects may consume huge amounts of
diskspace when using unusual blocksizes (e.g. 32KB). My setup is Postgresql-7.2.1
+ 32KB blocks + LOBLKSIZE 16KB, a unusual combination I think, , because this setup
+gave
the very best performance. I wanted to restore
53 matches
Mail list logo
