Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I prepared patch which use oid output function instead regproc output.
This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially not
like that.
OK, The behavior of regproc type is
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I prepared patch which use oid output function instead regproc output.
This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially not
like that.
OK, The
Alvaro Herrera napsal(a):
Zdenek Kotala wrote:
Tom Lane napsal(a):
Zdenek Kotala [EMAIL PROTECTED] writes:
I prepared patch which use oid output function instead regproc output.
This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially not
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, maybe it should be using regprocedure instead?
Not unless you want to break initdb. The only reason regproc still
exists, really, is to accommodate loading of pg_type during initdb.
Guess what: we can't do type lookup at that
Zdenek Kotala [EMAIL PROTECTED] writes:
I prepared patch which use oid output function instead regproc output.
This change works only for COPY TO command.
This is not a bug and we're not going to fix it, most especially not
like that.
regards, tom lane
I tried to use COPY command to export and import tables from catalog,
but COPY command has problem with data type regproc. See example
create table test (like pg_aggregate);
copy pg_aggregate to '/tmp/pg_agg.out';
copy test from '/tmp/pg_agg.out';
ERROR: more than one function named
Zdenek Kotala wrote:
I tried to use COPY command to export and import tables from catalog
Is it just me or does this seem like a strange thing to want to do? I am
trying to think of a good use case, so far without much success.
cheers
andrew
---(end of
Zdenek Kotala wrote:
I tried to use COPY command to export and import tables from catalog,
but COPY command has problem with data type regproc. See example
create table test (like pg_aggregate);
copy pg_aggregate to '/tmp/pg_agg.out';
copy test from '/tmp/pg_agg.out';
ERROR: more
Andrew Dunstan wrote:
Zdenek Kotala wrote:
I tried to use COPY command to export and import tables from catalog
Is it just me or does this seem like a strange thing to want to do? I am
trying to think of a good use case, so far without much success.
I'm playing with catalog upgrade. The
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, maybe it should be using regprocedure instead?
Not unless you want to break initdb. The only reason regproc still
exists, really, is to accommodate loading of pg_type during initdb.
Guess what: we can't do type lookup at that point.
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, maybe it should be using regprocedure instead?
Not unless you want to break initdb. The only reason regproc still
exists, really, is to accommodate loading of pg_type during initdb.
Guess what: we can't do type lookup at that
Zdenek Kotala wrote:
Andrew Dunstan wrote:
Zdenek Kotala wrote:
I tried to use COPY command to export and import tables from catalog
Is it just me or does this seem like a strange thing to want to do? I
am trying to think of a good use case, so far without much success.
I'm playing
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, maybe it should be using regprocedure instead?
Not unless you want to break initdb. The only reason regproc still
exists, really, is to accommodate loading of pg_type during initdb.
Guess what: we can't do type lookup at that
Zdenek Kotala [EMAIL PROTECTED] writes:
I'm playing with catalog upgrade. The very basic idea of my experiment
is export data from catalog and import it back to the new
initialized/fresh catalog.
That is never going to work, at least not for any interesting catalogs.
A system with a fresh (I
Zdenek Kotala [EMAIL PROTECTED] writes:
if( donot_resolve_procname == TRUE)
{
result = (char *) palloc(NAMEDATALEN);
snprintf(result, NAMEDATALEN, %u, proid);
}
What for? If you want numeric OIDs you can have that today by casting
the column to OID. More to the point,
Tom Lane wrote:
Zdenek Kotala [EMAIL PROTECTED] writes:
I'm playing with catalog upgrade. The very basic idea of my experiment
is export data from catalog and import it back to the new
initialized/fresh catalog.
That is never going to work, at least not for any interesting catalogs.
A system
Zdenek Kotala wrote:
Tom Lane wrote:
The right way to implement pg_upgrade is to transfer the catalog data
at the SQL-command level of abstraction, ie, pg_dump -s and reload.
I'm not sure if it is important, but I think that preserve OID is
important and SQL level does not allow set OID.
Andrew Dunstan [EMAIL PROTECTED] writes:
Zdenek Kotala wrote:
I'm not sure if it is important, but I think that preserve OID is
important and SQL level does not allow set OID.
Does it matter in any case other than where it refers to an on-disk
object? And does that need anything other than
18 matches
Mail list logo
