Mark Dilger wrote:
> >>
> >> relpartbound
> >> |
> >>
> >> relpartbound
> >> | ?column? | ?column?
> >> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+----------
> >> {PARTITIONBOUNDSPEC :strategy l :listdatums ({CONST :consttype 23000
> >> :consttypmod -1 :constcollid 0 :constlen 2 :constbyval true :constisnull
> >> false :location -1 :constvalue 2 [ 0 0 0 0 0 0 0 0 ]}) :lowerdatums <>
> >> :upperdatums <> :location 82} | {PARTITIONBOUNDSPEC :strategy l
> >> :listdatums ({CONST :consttype 23000 :consttypmod -1 :constcollid 0
> >> :constlen 2 :constbyval true :constisnull false :location -1 :constvalue 2
> >> [ 0 0 0 0 0 0 0 0 ]}) :lowerdatums <> :upperdatums <> :location 73} | f
> >> | f
> >> (1 row)
> I concede that mitigates the problem somewhat, though I still think a user
> may look
> at pg_class, see there is a column that appears to show the partition
> boundaries,
> and then decide to check whether two tables have the same partition boundaries
> by comparing those fields, without passing them first through pg_get_expr(), a
> function they may never have heard of.
How do you expect that the used would actually interpret the above
weird-looking value? There's no way to figure out what operations are
being done in that ugly blob of text.
I suspect it would be better to reduce the location field to -1 as
proposed, though, since the location has no actual meaning once the node
is stored standalone rather than as part of a larger command. However
it's clear that we're not consistent about doing this elsewhere.
> To me, it seems odd to immortalize a SQL parsing field in the catalog
> definition of
> the relation, but perhaps that's just my peculiar sensibilities. If the
> community is more
> on your side, I'm not going to argue it.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
