On Mon, 13 Jun 2005, Greg Stark wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
Why all the choices? What cases are there for doing one without the
other? If you want to get 'fine tuned', do a 'REINDEX TABLE' ... I can
see REINDEX SYSTEM and REINDEX DATABASE (includes SYSTEM), but not
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> >> Why all the choices? What cases are there for doing one without the
> >> other? If you want to get 'fine tuned', do a 'REINDEX TABLE' ... I can
> >> see REINDEX SYSTEM and REINDEX DATABASE (includes SYSTEM), but not the
> >> USER one ..
> >
> >
On Sun, Jun 12, 2005 at 11:48:29PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > I believe this isn't just my problem. Without access to a the
> > underlying column's DEFAULT, how can people implement the automated
> > WRITEable VIEWs?
>
> That's a reasonable question, but
On Sun, 2005-06-12 at 20:33 -0700, David Fetter wrote:
> On Sun, Jun 12, 2005 at 10:56:22PM -0400, Tom Lane wrote:
> > David Fetter <[EMAIL PROTECTED]> writes:
> > > At one time, INSERTing a NULL into a column with a DEFAULT used to
> > > INSERT the DEFAULT. Is there some way to get this behavior
David Fetter <[EMAIL PROTECTED]> writes:
> I believe this isn't just my problem. Without access to a the
> underlying column's DEFAULT, how can people implement the automated
> WRITEable VIEWs?
That's a reasonable question, but translating "insert null" to "insert
the default" is not a reasonable
On Sun, Jun 12, 2005 at 10:56:22PM -0400, Tom Lane wrote:
> David Fetter <[EMAIL PROTECTED]> writes:
> > At one time, INSERTing a NULL into a column with a DEFAULT used to
> > INSERT the DEFAULT. Is there some way to get this behavior back?
>
> PG has *never* done that in any version that I can r
It occurs to me that, because this restoration process is fundamentally
noninteractive, there is no longer any reason that we cannot support
backing up large objects in plain PSQL dumps. The dump script for
each LO would look something like
begin;
select lo_create(original-OID-of
David Fetter <[EMAIL PROTECTED]> writes:
> At one time, INSERTing a NULL into a column with a DEFAULT used to
> INSERT the DEFAULT. Is there some way to get this behavior back?
PG has *never* done that in any version that I can recall, and it isn't
likely that we would install such an obvious vio
I have just finished making a lo_create() function that accepts the
desired large object OID to create, as per recent discussion. This
means we can substantially reduce the complexity of pg_restore's
handling of LOs: we can remove the code that (tediously and rather
klugily) tries to find and upda
Folks,
At one time, INSERTing a NULL into a column with a DEFAULT used to
INSERT the DEFAULT. Is there some way to get this behavior back? I
think that this is a bug introduced by removing the NULL -> DEFAULT
behavior and not replacing it somehow. Below is a simple repro.
I think this is a bug
Check out EnterprisDB: www.enterprisedb.com
Chris
Edward Peschko wrote:
hey all,
I'm trying to convince some people here to adopt either mysql or postgresql
as a relational database here.. However, we can't start from a clean slate;
we have a very mature oracle database that applications poi
On Sun, 12 Jun 2005, Tom Lane wrote:
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
On Sat, 11 Jun 2005, Tom Lane wrote:
It's always bothered me too. How about
REINDEX SYSTEM -> system tables (current meaning of R. DATABASE)
REINDEX USER -> all non-system tables
REINDEX DATABASE -> both of t
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> What about just adding max(x,y) and min(x,y) to the system functions?
There's already a patch in the queue to do these using the Oracle
spellings (ie, GREATEST(...), LEAST(...)). ISTM that those are
better choices of name, because (a) they are a de fac
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> On Sat, 11 Jun 2005, Tom Lane wrote:
>> It's always bothered me too. How about
>>
>> REINDEX SYSTEM -> system tables (current meaning of R. DATABASE)
>> REINDEX USER -> all non-system tables
>> REINDEX DATABASE -> both of the above
> Why all the c
On Sat, 11 Jun 2005, Tom Lane wrote:
Bruce Momjian writes:
Kaare Rasmussen wrote:
I consider this a bug, or at least a badly thought out name. I can't
understand that someone approved 'reindex database' to mean 'reindex the
system tables of a database'.
Agreed.
It's always bothered me to
On Fri, Jun 10, 2005 at 03:04:49PM -0400, Tom Lane wrote:
> misc_utils: I believe that all of these utils are obsolesced by
> > builtin system commands or easily written userspace functions
> > (like max(x,y)). Also, is under the GPL (see above). Author
> > Massimo Dal Zotto ([EMAIL PROTECTED])
On Mon, Jun 06, 2005 at 12:52:13PM -0700, Edward Peschko wrote:
> In other words, I'm looking to make a postgresql -> Oracle mirroring
> tool, and syncing the databases on a nightly basis, and I was
> wondering if anybody had experience with this sort of thing.
You should take a look at contrib/d
What about:
ALTER [OBJECT] RENAME TO [schema.]name [CASCADE]
This has somewhat less new syntax.
CASCADE would also move dependant objects.
Perhaps trigger functions should not be moved, since it
is not really obvious how to do this right.
Warning should be issued in this case.
Command basically
On Tue, 2005-06-07 at 12:16, Jaime Casanova wrote:
> > SELECT encounter.encounter_id, encounter_d.encounter_d_id
> > FROM encounter
> > JOIN encounter_d on encounter_d.encounter_id = encounter.encounter_id
> > EXCEPT
> > SELECT encounter.encounter_id, encounter_d.encounter_d_id
> > FROM encounter
>
Dear Hackers,
I am trying to create a wrapper around Postgres on
Win32, but have found the macro used to export/import a little unhelpful.
Would it be worth considering modifying it from
DLLIMPORT to something like PGSQL_DLLIMPORT and instead of BUILDING_DLL to
PGSQL_BUILDING_DLL. This
On Fri, Jun 10, 2005 at 12:12:05PM -0400, Tom Lane wrote:
> Hannu Krosing <[EMAIL PROTECTED]> writes:
> > As the number of tuples between CTID_INDEX_MIN and CTID_INDEX_MAX is
> > finite, they must be added in finite time, by which time the index will
> > be up-to-date and usable for querie planner.
Wouldn't
ALTER [OBJECT] RENAME TO [schema.][name]
be a better?
After all, this is essentially a rename operation,
so maybe it is better to extend existing syntax...
5WD-02-Foundation-2003-09.pdf doesn't seem
to specify any renaming with ALTER TABLE...
---(end of broa
Hi!
Bruce Momjian [2005-06-06 21:23 -0400]:
>
> Is this a direction we want to explore --- using the SONAME as part of
> the translation domain?
If that would go upstream, so much the better. I already do it in the
Debian and Ubuntu packages since I don't have any choice anyway, and
it's not rea
hey all,
I'm trying to convince some people here to adopt either mysql or postgresql
as a relational database here.. However, we can't start from a clean slate;
we have a very mature oracle database that applications point to right now,
and so we need a migration path. I went to the mysql folks
On Fri, 10 Jun 2005, Neil Conway wrote:
Someone commented to me recently that they usually use psql's \x "expanded
output" mode, but find that it produces pretty illegible results for psql
slash commands such as \d. I can't really see a reason you would _want_
"expanded output" mode for the re
Oleg Bartunov writes:
> There is a problem with gist_xlog_cleanup function - we have no
> information about user defined functions and indices, because postmaster
> doesn't started yet and system catalog isn't available. For btree it's not
> necessary, but for GiST we certainly need them.
btree m
There is a problem with gist_xlog_cleanup function - we have no
information about user defined functions and indices, because postmaster
doesn't started yet and system catalog isn't available. For btree it's not
necessary, but for GiST we certainly need them. Is't possible to add
additional hook a
"Andrew Dunstan" <[EMAIL PROTECTED]> writes:
> Tom Lane said:
>> This seems awfully limiting; isn't return_next a better API?
> plperl already does return_next for handing data back to postgres (see
> recently applied patch). I don't understand how we can use it when fetching
> data from postgres
Tom Lane said:
> Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
>> I've been working on making it possible for PL/Perl users to fetch
>> large result sets one row at a time (the current spi_exec_query
>> interface just returns a big hash).
>
>> The idea is to have spi_query call SPI_prepare/SPI_open
Abhijit Menon-Sen <[EMAIL PROTECTED]> writes:
> I've been working on making it possible for PL/Perl users to fetch large
> result sets one row at a time (the current spi_exec_query interface just
> returns a big hash).
> The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have
> an
I've completed my first cut of adding a day field to the interval
struct and patched up the regression tests for places where it failed
due to the new behavior (e.g., interval '19:00' + interval '6:00' =
interval '25:00'). I haven't added any regression tests for the DST
behavior, but it wo
Hi,
On Sat, Jun 11, 2005 at 09:45:12PM -0400, Gregory Maxwell wrote:
> > - Who has permissions to set the user's quota per tablespace, the
> > superuser and the tablespace owner?
>
> It would be nice if this were nestable, that is, if the sysadmin could
> carve out a tablespace for a user then th
Hi.
I've been working on making it possible for PL/Perl users to fetch large
result sets one row at a time (the current spi_exec_query interface just
returns a big hash).
The idea is to have spi_query call SPI_prepare/SPI_open_cursor, and have
an spi_fetchrow that calls SPI_cursor_fetch. It works
33 matches
Mail list logo
